Log Date time zone

[+zikadu]

Since a few days there seem to be a problem with the different time zones when logging a cache. We are located in Germany and every cache we are logging as found before 9 AM (GMT +1) is registered as a found on the previous day. After 9 AM (GMT +1) the found is shown with the correct date.

We checked our time zone settings and these are correct. And we are quite sure that we hadn't encountered this problem in the past.

Any ideas?

[Blue Square Thing]

I've certainly had this problem in the past - from the UK. I think everything is set to US west coast time - i.e. GMT - 8.

 

From memory this has always been the case? I just get used to checking the date of logs!

[+Walts Hunting]

old old old well documented issue. Using something like gsak can correct this.

[jholly]

I've certainly had this problem in the past - from the UK. I think everything is set to US west coast time - i.e. GMT - 8.

 

From memory this has always been the case? I just get used to checking the date of logs!

The current offset is GMT-7.

[+EngPhil]

This is a never-ending cause of anguish for those of us in timezones like UTC+10. Anything logged here before 17:00 will generally have the wrong date.

 

(Some apps, like Geosphere, go to amazing lengths to work around this craziness, to ensure the date logged is correct. Most, including the Groundspeak ones, don't bother.)

[+The A-Team]

Some apps, like Geosphere, go to amazing lengths to work around this craziness, to ensure the date logged is correct.

Really? I don't see why they'd have to go to amazing lengths. The API call already accepts a date/time along with the log content, so an app can simply present the user with a date-picker and use that input to tell the Groundspeak servers which date to use for the log. This is why GSAK works - it uses the API and submits the correct date with the log.

 

Frankly, I'd be pretty surprised if any of the apps using the API didn't already do this, because it would be relatively simple to implement.

[+EngPhil]

Some apps, like Geosphere, go to amazing lengths to work around this craziness, to ensure the date logged is correct.

Really? I don't see why they'd have to go to amazing lengths. The API call already accepts a date/time along with the log content, so an app can simply present the user with a date-picker and use that input to tell the Groundspeak servers which date to use for the log. This is why GSAK works - it uses the API and submits the correct date with the log.

Yes, but the problem, as I understand it, is that that date/time has to be in Seattle's timezone. (Of course, once the log is published, it loses its "time" portion and is only represented as a date.)

 

So the horrid kludge is something like "find the first minute of the day in Seattle which corresponds to the same (calendar) day as the log time/date in the user's timezone, and use that".

 

And, from memory, the logic is different for Logs compared to Field Notes (which I think behave more predictably.)

 

Timezone handling has never been the Frog's strong suit. I'm not sure what GSAK does to compensate here.

 

Frankly, I'd be pretty surprised if any of the apps using the API didn't already do this, because it would be relatively simple to implement.

Don't take this the wrong way, but you clearly haven't had to put up with the mess that Groundspeak's own apps make of logs when you're as far ahead of their timezone as I am. Any caches logged direct from these apps are far more likely to be dated one day too early.....