5 ms·

Here is how I deal with the Time in the systems I design: 1. Always store time in UTC 2. If the time is tied to a fixed place, like start of a Football match,

Here is how I deal with the Time in the systems I design: 1. Always store time in UTC 2. If the time is tied to a fixed place, like start of a Football match, store the timezone of the place in another column, for example, Asia/Kolkata, America/New_York, etc 3. Always store user's timezone as part of their preferences. Helps in use cases like send the reminder to the user at 8:00AM in their timezone. 4. All APIs always return time in UTC and user's or the places timezone in the output. 5. It's the job of the frontend to convert the UTC time to proper timezone and display it to the user. Never had a use case I couldn't solve with these rules.

progval 5y ago
> the timezone of the place It's not always unique. For example, Xinjiang uses both UTC+8 (Beijing time) and UTC+6 (Xinjiang Time), depending on context. https://en.wikipedia.org/wiki/Xinjiang_Time https://en.wikipedia.org/wiki/Xinjiang_Time Even when unique, it can be hard to automatically find it. The US and Canada typically have timezones that don't exactly follow state/province borders (or even county borders). https://en.wikipedia.org/wiki/Time_in_the_United_States#Boundaries_between_the_zones https://en.wikipedia.org/wiki/Time_in_the_United_States#Boun...
- marcosdumay 5y ago
  Well, the rule to follow when you can't discover something by yourself is: ask the user. And for most things, even if you can discover it, let the user override your guess.
- hackernewds 5y ago
  That just means your data should have more context than Xinjiang. This is like saying the continent of Europe doesnt use the same tz, since the geo data logged is only in "continent" units
marcosdumay 5y ago
Do you store scheduled times, when the UTC representation of the local time can change between the times the user entering it and the event happening?
dathinab 5y ago
This approach has problems when the UTC <-> local time mapping changes, e.g. when: - a timezone changes - users change their timezone Often what the user wants is that the "naive" local time stays the same (e.g. it's still 12am even if the timezone changes). Through not always.
wolf550e 5y ago
I believe this is not correct for future scheduled events for humans. When a human sets an event for 8AM on some day 3 years in the future (maybe through a recurring weekly event), what they mean is "8AM local time in that jurisdiction". When a law passes that changes the daylight saving time amount or DST switch date or just sets the timezone to be different or the jurisdiction is merged into another or whatever, humans expect future scheduled events to adjust accordingly. Imagine a clock tower in the town square. If something political happens, it will be adjusted, and a meeting set to 8AM local time should occur according to that (possibly virtual) clock tower clock. That is why logs (moment of time in the past) should be stored in UTC (possibly with local or user's timezone name for UI), timers (short offsets into the future from a moment of time in the past) should be stored in UTC like logs, and future scheduled events between humans should be stored in local time with the name of the timezone. The name of a timezone is never the offset, it is always the jurisdiction that can change the rules and be merged into another, etc. When answering the question "what is the UTC time of a future scheduled appointment?", which is equivalent to "does it intersect a future scheduled appointment set in a different timezone on the same or adjacent dates?", which is also equivalent to the question "how many seconds in the future is this from right now?", you must assume the timezone rules set by politicians will not change between now and the appointment time. If the appointment time is soon (e.g. under 3 months), you indeed can assume this, because legislating an unexpected timezone change that will take effect "soon" is stupid and will usually not be done. But for a scheduled appointment a year from now? You honestly don't know. You can guess, but you must assume this can change by a TZ database update and act accordingly. If you have converted from localtime to UTC when the appointment was created, it is difficult to adjust correctly when TZ db is updated. If you translate to UTC only "just in time" when rendering or detecting collisions, everything will work correctly.
- dotancohen 5y ago
  Actually, logs should be Unix timestamps in my opinion. It is a record of an event that occurred at a specific instant, regardless of how the user wants to see it formatted.
  - rhn_mk1 5y ago
wizerno 5y ago
I am currently working on a product which followed what you mentioned above. The problem we ran into is what the author of the article highlights. You cannot convert stored UTC times to local timezones reliably wihtout additional information. For example, for a conference whose starting time is stored as 14:00 Hrs UTC (0900 Hrs America/New_York) before DST, will suddenly start at 10:00 Hrs America/New_York after DST. Coincidentally, we just redid our implementation to follow Option 3 before New York's DST kicks in and it works as expected so far. Please correct me if my understanding of your method is incorrect.
- pritambarhate 5y ago
  The standard date time library of your programming language should be able to handle the DST changes when you specify the timezone changes when you store it as "America/New_York". Java (which I use primarily) Date Time lib handles this for you.
dotancohen 5y ago
How do you handle an alarm set for 02:30 on the date that the jumps _back_ from 03:00 to 02:00? How do you handle an alarm set for 02:30 on the date that the jumps _forward_ from 02:00 to 03:00?
- Izkata 5y ago
  At least over here that first one is 2:00 -> 1:00
- pritambarhate 5y ago
  Those are invalid times. Your date time validation should report an error to the user. For recurring scheduled reminders, I would remind them at 1:00AM along with explanation why they are getting that reminder early. There is no way to automatically handle this to my knowledge. So it's an edge case one must handle.
  - dotancohen 5y ago
    You could argue that the case of the clock jumping forward is an invalid time. But the case of the clock jumping back is in fact a valid time, even if it is non-unique.
stingraycharles 5y ago
How would you handle reporting, where you would for example want to aggregate by hour of day, localized by time zone? To me it seems impossible to do that kind of reporting, unless the backend is able to use the time zone to accurately convert the UTC time to hour-of-day, including DST shenanigans and whatnot.
- pritambarhate 5y ago
  >> unless the backend is able to use the time zone to accurately convert the UTC time to hour-of-day, including DST shenanigans and whatnot. Most mature date time libs can handle DST automatically for you when you use "named" timezones. For example, Java can handle it properly.

progval 5y ago

> the timezone of the place It's not always unique. For example, Xinjiang uses both UTC+8 (Beijing time) and UTC+6 (Xinjiang Time), depending on context. https://en.wikipedia.org/wiki/Xinjiang_Time https://en.wikipedia.org/wiki/Xinjiang_Time Even when unique, it can be hard to automatically find it. The US and Canada typically have timezones that don't exactly follow state/province borders (or even county borders). https://en.wikipedia.org/wiki/Time_in_the_United_States#Boundaries_between_the_zones https://en.wikipedia.org/wiki/Time_in_the_United_States#Boun...

marcosdumay 5y ago
Well, the rule to follow when you can't discover something by yourself is: ask the user. And for most things, even if you can discover it, let the user override your guess.
hackernewds 5y ago
That just means your data should have more context than Xinjiang. This is like saying the continent of Europe doesnt use the same tz, since the geo data logged is only in "continent" units

marcosdumay 5y ago

Do you store scheduled times, when the UTC representation of the local time can change between the times the user entering it and the event happening?

dathinab 5y ago

This approach has problems when the UTC <-> local time mapping changes, e.g. when: - a timezone changes - users change their timezone Often what the user wants is that the "naive" local time stays the same (e.g. it's still 12am even if the timezone changes). Through not always.

wolf550e 5y ago

I believe this is not correct for future scheduled events for humans. When a human sets an event for 8AM on some day 3 years in the future (maybe through a recurring weekly event), what they mean is "8AM local time in that jurisdiction". When a law passes that changes the daylight saving time amount or DST switch date or just sets the timezone to be different or the jurisdiction is merged into another or whatever, humans expect future scheduled events to adjust accordingly. Imagine a clock tower in the town square. If something political happens, it will be adjusted, and a meeting set to 8AM local time should occur according to that (possibly virtual) clock tower clock. That is why logs (moment of time in the past) should be stored in UTC (possibly with local or user's timezone name for UI), timers (short offsets into the future from a moment of time in the past) should be stored in UTC like logs, and future scheduled events between humans should be stored in local time with the name of the timezone. The name of a timezone is never the offset, it is always the jurisdiction that can change the rules and be merged into another, etc. When answering the question "what is the UTC time of a future scheduled appointment?", which is equivalent to "does it intersect a future scheduled appointment set in a different timezone on the same or adjacent dates?", which is also equivalent to the question "how many seconds in the future is this from right now?", you must assume the timezone rules set by politicians will not change between now and the appointment time. If the appointment time is soon (e.g. under 3 months), you indeed can assume this, because legislating an unexpected timezone change that will take effect "soon" is stupid and will usually not be done. But for a scheduled appointment a year from now? You honestly don't know. You can guess, but you must assume this can change by a TZ database update and act accordingly. If you have converted from localtime to UTC when the appointment was created, it is difficult to adjust correctly when TZ db is updated. If you translate to UTC only "just in time" when rendering or detecting collisions, everything will work correctly.

dotancohen 5y ago
Actually, logs should be Unix timestamps in my opinion. It is a record of an event that occurred at a specific instant, regardless of how the user wants to see it formatted.
- rhn_mk1 5y ago

wizerno 5y ago

I am currently working on a product which followed what you mentioned above. The problem we ran into is what the author of the article highlights. You cannot convert stored UTC times to local timezones reliably wihtout additional information. For example, for a conference whose starting time is stored as 14:00 Hrs UTC (0900 Hrs America/New_York) before DST, will suddenly start at 10:00 Hrs America/New_York after DST. Coincidentally, we just redid our implementation to follow Option 3 before New York's DST kicks in and it works as expected so far. Please correct me if my understanding of your method is incorrect.

pritambarhate 5y ago
The standard date time library of your programming language should be able to handle the DST changes when you specify the timezone changes when you store it as "America/New_York". Java (which I use primarily) Date Time lib handles this for you.

dotancohen 5y ago

How do you handle an alarm set for 02:30 on the date that the jumps _back_ from 03:00 to 02:00? How do you handle an alarm set for 02:30 on the date that the jumps _forward_ from 02:00 to 03:00?

Izkata 5y ago
At least over here that first one is 2:00 -> 1:00
pritambarhate 5y ago
Those are invalid times. Your date time validation should report an error to the user. For recurring scheduled reminders, I would remind them at 1:00AM along with explanation why they are getting that reminder early. There is no way to automatically handle this to my knowledge. So it's an edge case one must handle.
- dotancohen 5y ago
  You could argue that the case of the clock jumping forward is an invalid time. But the case of the clock jumping back is in fact a valid time, even if it is non-unique.

stingraycharles 5y ago

How would you handle reporting, where you would for example want to aggregate by hour of day, localized by time zone? To me it seems impossible to do that kind of reporting, unless the backend is able to use the time zone to accurately convert the UTC time to hour-of-day, including DST shenanigans and whatnot.

pritambarhate 5y ago
>> unless the backend is able to use the time zone to accurately convert the UTC time to hour-of-day, including DST shenanigans and whatnot. Most mature date time libs can handle DST automatically for you when you use "named" timezones. For example, Java can handle it properly.