Incorrect timezone indicated on local dates

[Dave Hughes]

I've noticed that date fields normally come in pairs, such as start_date and start_date_local.  These dates exist for activities, best efforts, segment efforts, laps, and more.

I'm not sure if the issue is with the data being saved to Strava (from the Strava Android app) or more likely the API's output, but for the start_date_local, even though the time is correct, the timezone is not.  The value returned for both date fields is in the format 2018-10-21T16:11:02Z (ISO8601).  The Z is a timezone indicator, meaning UTC/GMT.  This means that if we read the start_date_local field and attempt to print it in the user's local time, it will end up incorrect (by the number of hours between UTC and the user's timezone).

It would be great if the *_date_local fields correctly indicated the local timezone.  For the example given above, the start_date_local recorded in PDT should be 2018-10-21T16:11:02-07:00, which is equivalent to the start_date value of 2018-10-21T23:11:02Z.

[Dave Hughes]

I forwarded this on to the API team.  They have confirmed that these dates are being reported incorrectly and have logged it internally, but they also suggested that it will likely not be fixed any time soon.  When it does get resolved, it will likely be through the deprecation of the *_date_local fields, which may be replaced with some other field.

[Jeffrey Friedl]

> When it does get resolved, it will likely be through the deprecation of
> the *_date_local fields, which may be replaced with some other field.

That seems prudent, since whatever those field have been, people have learned to use them as is.

I reported their inconsistency a few years ago, but it was clear that they were designed by
someone who simply didn't understand the concept of UnixTime. That lack of understanding may
well be enshrined in the underlying database design, so a fix may be impossible.

>It would be great if the *_date_local fields correctly indicated the local timezone.

This is almost impossible to do reliably, without input from the user. Timezone regions in The States
are mostly static, so one could be fairly confident about it when the locations are not near timezone
borders, but to solve the problem worldwide would be.... challenging.

Jeffrey

[Dave Hughes]

Thanks for the info, Jeffrey.

 

That seems prudent, since whatever those field have been, people have learned to use them as is. 

I agree that they shouldn't change the existing fields.  I wasn't criticizing that decision, just disseminating information that was shared with me.

This is almost impossible to do reliably, without input from the user

I don't follow your reasoning about timezone information being impossible to include.  Activities are recorded with the devices time information.  Reviewing the GPX from an activity recorded by the Strava Android App, it is recorded in UTC (2018-11-02T23:33:58Z).  I suppose there could be some complexity if the user crosses a timezone border  or Daylight Savings starts/ends while recording an activity, but I would expect that GPS devices typically have a way of handling this (such as recording all data in the timezone where the recording began).

Some entities (at least Activity) already include timezone information.  Although, as I review that right now, I notice another error/inconsistency there: the timezone on one of my recent activities reports as "(GMT-08:00) America/Vancouver", but we are still in daylight savings time, so it should be "(GMT-07:00) America/Vancouver".  Interestingly, the utc_offset is -25200 (7 hours in seconds), which is correct.

Dave

[Jeffrey Friedl]

> but I would expect that GPS devices typically have a way of handling this (such as recording all data in the timezone where the recording began).

Data in tracklogs is explicitly in UTC (GMT), regardless of where in the universe the recording is done.
Activities recorded with a device that know the timezone could plausably somehow inform Strava about the
timezone at the activity start and end, and this would be useful in the common case, but one has to also
deal with edge cases, such as head units that don't know the user's timezone, or someone uploading a bunch
of activity files accumulated over the years, perhaps from all around the world, and all without any
timezone data. The devil's in the details....

Jeffrey