I agree on the point of always be converting, but I'll settle with UTC. IMHO if you have a non-utc time one if two things should happen:
A.) Convert it to Utc.
B.) Show it to someone.
Got some 'splain'n to do if I catch non-utc manipulation or comparison going on in my code bases. And heaven help you should you stick a non-utc time into the database.
These are all good points and I have thought about it a lot.. It seems that all these issues arise from people wanting to schedule or track a future date that is itself tentative and ambiguous; at the mercy of policy changes.
Ignoring the case where you want to allow a user to track some tentative future date that can resolve to different absolute times there is another truth there: You recorded a future absolute time which now maps to a different local time due to your government mucking about. What about the people in Hamburg who were supposed to join the meeting but missed it because the absolute time shifted?
For usability sake I do absolutely see where you are coming from and the library is surely nice. But I'll stick with storing and mathing UTC unless I absolutely need to start taking these scheduling issues into account :)
I'm not sure I understand the point of saving the offset:
"To avoid ambigiuty we also save a third piece of data: the UTC offset. Note that the UTC offset is only there for the rare cases when the timezone does not change, but when there is an ambiguity we know about at scheduling time - that will usually be when the timezone goes off of DST and a range of time (usually an hour) happens twice in autumn when clocks are set back. In this example though this third piece of data is not used for anything."
This doesn't make sense to me? Great read otherwise. I hadn't considered this edge case!
The reason the offset is changed is ambigous datetimes that occur when going off of DST.
Let us say a user enters a datetime in the autumn. It happens to be a few minutes after the clocks are set back an hour. So the time is ambiguous. Which datetime exactly does the user want? The one before or after the clocks are set back? We show him a dialog and he chooses one. To differentiate we use the standard offset which is usally 0 or 3600 seconds.
Great, now we save it to the database as just wall time and timezone name and load it again. How do we know if it is 02:05 before the clocks are set back or 02:05 after the clocks are set back? We don't, unless we saved the UTC offset. But if we save the offset we know exactly which one it is.
But we don't want to use the offset we calculated from the beginning. That would get us the same error as if saving just the UTC time. So we only use the offset if we absolutely have to. This is what Kalecto does when loading a saved datetime from the library: we do the calculation based on the saved "wall time" and the timezone name. If that wall time is ambiguous we use the UTC offset. If there were no changes to the rules for that timezone - no problems.
Now, if we have a combination of the timezone rules changing and the saved datetime being ambiguous, the entered choice is no longer valid. We have to ask the user again or report an error.
Why do you prefer UTC? I feel storing plain unix times is simplest since there's no time zone information at all. And there's no possibility of forgetting a conversion, since (with most languages/libraries) different types are used for plain unix times vs. local times.
Just to be make sure we're talking about the same thing, by "plain unix time" I mean something like java.time.Instant, and by "UTC time" I mean something like java.time.ZonedDateTime with zone == UTC.
With ZonedDateTime, there's obviously a time zone field. We can have a convention of always setting it to UTC, but that introduces a possible source of bugs. We might call ZonedDateTime.now() and forget to pass an explicit zone. Especially if the author is a new contributor who hasn't been told about our convention.
Or we might use a library which produces ZonedDateTimes with the system's default zone. Then we have to canonicalize them at some point, and be very careful not to rely on the local date/time info prior to canonicalization.
I'd rather just use a type like Instant which has no time zone field, so that there's no need for any time zone convention.
Further, we might need to serialize a timestamp using a non-UTC timezone, say CST which is common in payments systems. If we're using UTC times, we might forget to convert from UTC to CST. If we're using a plain unix time, we're forced to specify a time zone when serializing, so it's harder to make a mistake.
Comments
I agree on the point of always be converting, but I'll settle with UTC. IMHO if you have a non-utc time one if two things should happen:
A.) Convert it to Utc.
B.) Show it to someone.
Got some 'splain'n to do if I catch non-utc manipulation or comparison going on in my code bases. And heaven help you should you stick a non-utc time into the database.
Here is an example where the "convert it to UTC" rule would fail: http://www.creativedeletion.com/2015/03/19/persisting_future...
I will stick non-UTC time into the database and I made a library to do it.
These are all good points and I have thought about it a lot.. It seems that all these issues arise from people wanting to schedule or track a future date that is itself tentative and ambiguous; at the mercy of policy changes.
Ignoring the case where you want to allow a user to track some tentative future date that can resolve to different absolute times there is another truth there: You recorded a future absolute time which now maps to a different local time due to your government mucking about. What about the people in Hamburg who were supposed to join the meeting but missed it because the absolute time shifted?
For usability sake I do absolutely see where you are coming from and the library is surely nice. But I'll stick with storing and mathing UTC unless I absolutely need to start taking these scheduling issues into account :)
I'm not sure I understand the point of saving the offset:
"To avoid ambigiuty we also save a third piece of data: the UTC offset. Note that the UTC offset is only there for the rare cases when the timezone does not change, but when there is an ambiguity we know about at scheduling time - that will usually be when the timezone goes off of DST and a range of time (usually an hour) happens twice in autumn when clocks are set back. In this example though this third piece of data is not used for anything."
This doesn't make sense to me? Great read otherwise. I hadn't considered this edge case!
The reason the offset is changed is ambigous datetimes that occur when going off of DST.
Let us say a user enters a datetime in the autumn. It happens to be a few minutes after the clocks are set back an hour. So the time is ambiguous. Which datetime exactly does the user want? The one before or after the clocks are set back? We show him a dialog and he chooses one. To differentiate we use the standard offset which is usally 0 or 3600 seconds.
Great, now we save it to the database as just wall time and timezone name and load it again. How do we know if it is 02:05 before the clocks are set back or 02:05 after the clocks are set back? We don't, unless we saved the UTC offset. But if we save the offset we know exactly which one it is.
But we don't want to use the offset we calculated from the beginning. That would get us the same error as if saving just the UTC time. So we only use the offset if we absolutely have to. This is what Kalecto does when loading a saved datetime from the library: we do the calculation based on the saved "wall time" and the timezone name. If that wall time is ambiguous we use the UTC offset. If there were no changes to the rules for that timezone - no problems.
Now, if we have a combination of the timezone rules changing and the saved datetime being ambiguous, the entered choice is no longer valid. We have to ask the user again or report an error.
I hope this explains it better.
Yes much better thanks!
Why do you prefer UTC? I feel storing plain unix times is simplest since there's no time zone information at all. And there's no possibility of forgetting a conversion, since (with most languages/libraries) different types are used for plain unix times vs. local times.
There's no time zone information in UTC either. People often mistake UTC for a time zone, but it isn't actually one.
Just to be make sure we're talking about the same thing, by "plain unix time" I mean something like java.time.Instant, and by "UTC time" I mean something like java.time.ZonedDateTime with zone == UTC.
With ZonedDateTime, there's obviously a time zone field. We can have a convention of always setting it to UTC, but that introduces a possible source of bugs. We might call ZonedDateTime.now() and forget to pass an explicit zone. Especially if the author is a new contributor who hasn't been told about our convention.
Or we might use a library which produces ZonedDateTimes with the system's default zone. Then we have to canonicalize them at some point, and be very careful not to rely on the local date/time info prior to canonicalization.
I'd rather just use a type like Instant which has no time zone field, so that there's no need for any time zone convention.
Further, we might need to serialize a timestamp using a non-UTC timezone, say CST which is common in payments systems. If we're using UTC times, we might forget to convert from UTC to CST. If we're using a plain unix time, we're forced to specify a time zone when serializing, so it's harder to make a mistake.
Unless your users are happy to view UTC you will have to deal with it when you display it to them.