4 ms·

Actually the meaning of a date like: 2018-05-26T13:45:21+02:00 Will never change, regardless how many time zone changes you may have. What does change is the

Actually the meaning of a date like: 2018-05-26T13:45:21+02:00 Will never change, regardless how many time zone changes you may have. What does change is the method to compute the time difference. So can you say how many days, hours, minutes, seconds ago that was from: 2043-02-12T11:15:16+02:00 You won’t be able to, because then you have to account for leap seconds, etc. Also “next Tuesday” does have to take into account the time zone as you may need to deal with daylight saving time. However “next Tuesday” is not a date-time, but a relative difference from where you are now and by pre-calculating you lose information. Also relevant, in such cases storing the time zone doesn’t help because the user himself might travel and next Tuesday at 7:00 can remain the same, no matter what time zone you’re talking about.

0x0 8y ago
It depends. It could be a meeting in a particular city at 4pm local time. A "+02:00" or "-05:00" specifier is insufficient because the government of the particular city/country might change the time zone rules between now and when the event is to occur. So you really need to store "2018-08-01 16:00:00 America/Argentina/Buenos Aires" for example, because maybe after 2018-06-01 they decided to go for "-05:30".
- lomnakkus 8y ago
  Indeed. There's a concept of relative physical time a) "I'll be there in 12 hours", implication being that if there happens to be a DST change, it doesn't matter. and relative calendar time b) "I'll meet you 15:00 next monday". Both of which are valid. What's interesting is: which of these is most useful in programming, generally? Which should the APIs make easier, or even cater for at all? I would submit that most applications only care about "physical time"[1], but specifically [b]logging[/b] is actually really interested in calendar time. Fortunately, with logging there's so much volume that you can usually tell pretty easily when there's been a discontinuous time event -- it's a pain in the ass to rebuild timestamps, post hoc, though. [1] Calender-type application is actually pretty niche IME. Opinion may vary.
wlesieutre 8y ago
The meaning of “2018-05-26T13:45:21+02:00” may not change, but if 2018-05-26 rolls around and the restaurant where you have a lunch reservation at 13:45 local time is no longer in the +02:00 time zone, it’s not the same time that your reservation is scheduled for anymore.
pathseeker 8y ago
>Actually the meaning of a date like: 2018-05-26T13:45:21+02:00 Will never change, It will respective to the local time though if a state decides to stop honoring DST or changes TZ.
- perl4ever 8y ago
  I once ran across a book of changes over time to local time zones, I believe for historical research. It was the size of a phone book. Ah yes, American Atlas: United States Latitudes, Longitudes, Time Changes and Time Zones 5th Edition by Thomas G. Shanks 448 pages. Covers probably well over 100K locations each with its own history of timekeeping.
ivanhoe 8y ago
The meaning of the date will not change compared to the UTC absolute coordinates, but usually users care only about their local time. If you set an alarm to wake you up at 8:00, you expect it to ring at 8am your time every day. What if in future user's local time zone gets changed - say if daylight savings are abandoned, as many countries consider doing - The user might not be in +2 offset anymore and when you convert it to the local time the alarm will ring at 7am or 9am instead of 8:00. It's definitely not what user would expect.
- hrktb 8y ago
  what the user expect is of course completely different if there’s not one but several users, or several referentials. Then adapting for local time will screw any schedule not pegged to local time (even for stuff as trivial as following an international event) Time is hard.
cryptonector 8y ago
But users want wall clock time. That you stored 2018-05-26T13:45:21+02:00 is irrelevant. The user wants that time to change if the original timezone's definition changes. So you really need to store {datetime, timezone_name}. It gets tricky when you don't know the timezone... For example, you're on a plane with your devices in airplane mode and no wifi connectivity, and you want to create a calendar event in destination time... The UI had better let you specify a TZ, and you'll have to know what it is. Whereas if you want until you land you can just let your devices figure out what TZ you're in and spare you the bother of thinking about it. That's an unlikely edge case, but the UI should really let you input a TZ if you want to. Perhaps the UI should insist on you entering a TZ if you're in airplane mode.

0x0 8y ago

It depends. It could be a meeting in a particular city at 4pm local time. A "+02:00" or "-05:00" specifier is insufficient because the government of the particular city/country might change the time zone rules between now and when the event is to occur. So you really need to store "2018-08-01 16:00:00 America/Argentina/Buenos Aires" for example, because maybe after 2018-06-01 they decided to go for "-05:30".

lomnakkus 8y ago
Indeed. There's a concept of relative physical time a) "I'll be there in 12 hours", implication being that if there happens to be a DST change, it doesn't matter. and relative calendar time b) "I'll meet you 15:00 next monday". Both of which are valid. What's interesting is: which of these is most useful in programming, generally? Which should the APIs make easier, or even cater for at all? I would submit that most applications only care about "physical time"[1], but specifically [b]logging[/b] is actually really interested in calendar time. Fortunately, with logging there's so much volume that you can usually tell pretty easily when there's been a discontinuous time event -- it's a pain in the ass to rebuild timestamps, post hoc, though. [1] Calender-type application is actually pretty niche IME. Opinion may vary.

wlesieutre 8y ago

The meaning of “2018-05-26T13:45:21+02:00” may not change, but if 2018-05-26 rolls around and the restaurant where you have a lunch reservation at 13:45 local time is no longer in the +02:00 time zone, it’s not the same time that your reservation is scheduled for anymore.

pathseeker 8y ago

>Actually the meaning of a date like: 2018-05-26T13:45:21+02:00 Will never change, It will respective to the local time though if a state decides to stop honoring DST or changes TZ.

perl4ever 8y ago
I once ran across a book of changes over time to local time zones, I believe for historical research. It was the size of a phone book. Ah yes, American Atlas: United States Latitudes, Longitudes, Time Changes and Time Zones 5th Edition by Thomas G. Shanks 448 pages. Covers probably well over 100K locations each with its own history of timekeeping.

ivanhoe 8y ago

The meaning of the date will not change compared to the UTC absolute coordinates, but usually users care only about their local time. If you set an alarm to wake you up at 8:00, you expect it to ring at 8am your time every day. What if in future user's local time zone gets changed - say if daylight savings are abandoned, as many countries consider doing - The user might not be in +2 offset anymore and when you convert it to the local time the alarm will ring at 7am or 9am instead of 8:00. It's definitely not what user would expect.

hrktb 8y ago
what the user expect is of course completely different if there’s not one but several users, or several referentials. Then adapting for local time will screw any schedule not pegged to local time (even for stuff as trivial as following an international event) Time is hard.

cryptonector 8y ago

But users want wall clock time. That you stored 2018-05-26T13:45:21+02:00 is irrelevant. The user wants that time to change if the original timezone's definition changes. So you really need to store {datetime, timezone_name}. It gets tricky when you don't know the timezone... For example, you're on a plane with your devices in airplane mode and no wifi connectivity, and you want to create a calendar event in destination time... The UI had better let you specify a TZ, and you'll have to know what it is. Whereas if you want until you land you can just let your devices figure out what TZ you're in and spare you the bother of thinking about it. That's an unlikely edge case, but the UI should really let you input a TZ if you want to. Perhaps the UI should insist on you entering a TZ if you're in airplane mode.