parking_time is in wrong timezone

zzarne commented 3 years ago

My e-Up! 2020s parking time is off by 2 hours, which is the difference between my timezone and UTC. This is most likely not a bug in volkswagencarnet, as the same time can be seen in the data received:

{
    'findCarResponse': {
        'Position': {
            'timestampCarSent': '2021-05-06T16:53:58',
            'timestampTssReceived': datetime.datetime(2021, 5, 6, 16, 53, 58, tzinfo = datetime.timezone.utc),
            'carCoordinate': {
                'latitude': 12345,
                'longitude': 67890
            },
            'timestampCarSentUTC': datetime.datetime(2021, 5, 6, 14, 53, 49, tzinfo = datetime.timezone.utc),
            'timestampCarCaptured': '2021-05-06T16:53:58'
        },
        'parkingTimeUTC': datetime.datetime(2021, 5, 6, 14, 53, 49, tzinfo = datetime.timezone.utc)
    }
}

The car was parked at 18:53 local time (16:53 UTC).

I can only speculate about the reason:

the car sends data with a wrong timezone
the servers assume or apply a wrong timezone to the data from the car
there is something wrong when converting the json data from the servers to a python dict (but only in some cases - timestampTssReceived seem correct)

Is anyone else seeing this?

milkboy commented 2 years ago

Definitely something fishy with the parking time. Today I got a "parking time stamp" displaying 10:29, while the last drive ended 13:28. My timezone is UTC+2 (EET), so this makes no sense whatsoever.

milkboy commented 2 years ago

Did a little bit of log digging..

2022-02-14 19:18:22 DEBUG
{
  'findCarResponse': {
    'Position': {
      'timestampCarSent': '2022-02-14T17:17:48',
      'timestampTssReceived': datetime.datetime(2022, 2, 14, 17, 17, 48, tzinfo=datetime.timezone.utc),
      'carCoordinate': {
        'latitude': <snip>>,
        'longitude': <snap>
      },
      'timestampCarSentUTC': datetime.datetime(2022, 2, 14, 16, 17, 33, tzinfo=datetime.timezone.utc),
      'timestampCarCaptured': '2022-02-14T17:17:48'
    },
    'parkingTimeUTC': datetime.datetime(2022, 2, 14, 16, 17, 33, tzinfo=datetime.timezone.utc)
  }
}

And a pic of when the car was actually parked:

So from this I can gather that

"timestampCarSent" is the correct UTC time (but it's formatted as a local time)
"timestampTssReceived" is the correct UTC time for what the backend recorded as time when the update was received
"timestampCarSentUTC" is one hour off
"timestampCarCaptured" is the correct time in UTC (but formatted as local time)
"parkingTimeUTC" is the same bogus time as "timestampCarSentUTC"

Not sure if it has anything to do with this, but the car was originally sold in Germany (which is UTC+1)

Was your car by any chance imported from a different time zone @zzarne ?

Anyway, I guess we should change the logic to work around the bad data from the backend, but would really like to see the response from someone who has the correct parkingTimeUTC showing (if there is anyone... @robinostlund maybe? Or @tubalainen)

zzarne commented 2 years ago

Was your car by any chance imported from a different time zone @zzarne ?

No, my car was first sold to me, in Germany, where it still is. (Like all e-Up!s, it was built in Bratislava though.)

Anyway, I guess we should change the logic to work around the bad data from the backend, but would really like to see the response from someone who has the correct parkingTimeUTC showing (if there is anyone... @robinostlund maybe? Or @tubalainen)

I'd like to see more offsets, too, so we can figure out the sick logic behind this. Really, VW, failing to convert a GPS timestamp to UTC, which is a no-op? This is driving me mad.

No other value is exactly like parkingTimeUTC but with the correct timezone. The library could fake parking_time from any other timestamp received in findCarResponse, but there is no guarantee that this will always be a correct parking time for every car.

One way to fix it (from known data, sample size 3, hopefully growing) is adding the DST-aware timezone offset of Europe/Berlin, regardless.

milkboy commented 2 years ago

would be awesome if someone west of UTC could provide debug info also, but from this (way too small) sample size, it looks like the parking time might be one hour off. Anyway, dates are hard, time zones are hard. Plenty of examples on TDWTF :smirk:

zzarne commented 2 years ago

would be awesome if someone west of UTC could provide debug info also

Yes please. Someone?

[...] from this (way too small) sample size, it looks like the parking time might be one hour off.

In winter. In summer it's two hours, at least for me. My current theory is that somewhere in the VW cloud, the correct UTC timestamp is interpreted as CET/CEST (zoneinfo "Europe/Berlin") and converted to UTC; introducing the error.

Anyway, dates are hard, time zones are hard.

I know :)

I was wondering if the parking time was shown on any official VW app or website and if so, correctly. I can only find trip data, but that's not the same and already correctly represented in volkswagencarnet.

milkboy commented 2 years ago

Don't think it's shown anywhere... maybe because they never figured out why it's wrong? :trollface:

milkboy commented 2 years ago

hmm... also the "last status update" timestamp is wrong... :panda_face:

robinostlund commented 2 years ago

Mine shows correct :D

milkboy commented 2 years ago

Mine shows correct :D

hmmm.. something hard coded to Swedish time? :D

robinostlund commented 2 years ago

maby :D think we should change the sensor device class datetime or something as the history of it defaults to number :)

milkboy commented 2 years ago

{
  'id': '0x0101010001',
  'field': [
    {
      'id': '0x0101010001',
      'tsCarSentUtc': datetime.datetime(2022, 2, 18, 11, 36, 3, tzinfo=datetime.timezone.utc),
      'tsCarSent': '2022-02-18T12:36:14',
      'tsCarCaptured': '2022-02-18T12:36:14',
      'tsTssReceivedUtc': datetime.datetime(2022, 2, 18, 12, 36, 14, tzinfo=datetime.timezone.utc),
      'value': 'echo'
    }
  ]
}

okay.. so it really looks like the car is actually sending the wrong UTC time on everything, but the backend (received) timestamp is correct.. It might be a bug in the car software :rofl:

Wonder if it's fixable by comparing the timestamps, and offsetting the "car" ts by the difference in hours.. or something..

zzarne commented 2 years ago

hmm... also the "last status update" timestamp is wrong...

" Last Connected" is correct for my car.

zzarne commented 2 years ago

Mine shows correct :D

@robinostlund your Last Connected, Parking Time or both?

milkboy commented 2 years ago

aight.. Summer time again.. And the parking time is still showing in (UTC+1) instead of EEST (UTC+3).. So in winter it's 1 hour off, and summer 2 hours :D

zzarne commented 2 years ago

Here's my workaround. Replace CAR as appropriate and use the template sensor instead of the original one. This only works correctly if the car's timezone matches your local timezone.

template:
  sensor:
    - name: "CAR Sane parking time "
      state: >-
        {{ (states("sensor.CAR_parking_time") | as_timestamp(default="unavailable") + now().utcoffset().total_seconds()) | timestamp_custom('%Y-%m-%d %H:%M:%S') }}

robinostlund / volkswagencarnet

parking_time is in wrong timezone #121