4 ms·

I disagree. Storing as UTC is the only sane way. It will never get corrupted. Calculating the timezone difference for the user is not that hard and won't result

by feld 11y ago

I disagree. Storing as UTC is the only sane way. It will never get corrupted. Calculating the timezone difference for the user is not that hard and won't result in a database full of mistakes you have to scramble to fix.

Avernar 11y ago
Not for events like shows, movies, work hours, etc. An event starts and stops at a specific local time. If the DST rules change then the UTC version will be wrong but the one stored in local time + TZ will be correct. Intervals should be stored in UTC. If you're supposed to drop the control rods in a reactor in 24 hours you store the time it's supposed to happen in UTC. DST transitions and rule changes would mess this up if stored in local time. Timestamps for logs and files should also always be UTC.
- feld 11y ago
  UTC is an anchor. It does not change, it is never wrong. Your application or environment may live under different rules because of location but that problem can be solved by the timezone-aware application. If I am scheduling an event at 08:00 and my TZ is -5, the event is at 13:00 UTC. If my timezone changes due to a new law UTC is not wrong; the event is still going to happen at 13:00 UTC! If the event was previously stored as a local time and not UTC the EVENT is wrong! You solve this by handling the TZ conversion elsewhere and making sure it always has the latest rules. Always store in UTC. Your argument makes no sense.
  - laut 11y ago
    If the user expects 8:00 local time then it should stay 8:00 local time. That is at least how people would want their applications to work 99% of the time. If someone enters 8:00 and then the software suddenly changes it to something else, that is confusing. If you actually look at what happens when timezone laws change, people continue to anchor to their local times.
    - feld 11y ago
      Congratulations you literally just rescheduled the event. This is not a timezone issue. The date should still be stored as UTC.
      - Avernar 11y ago
        Wrong. Let's say an event is scheduled for 6pm daily in Toronto (EST -0500). You store it as 11pm UTC. Now eventually we switch to EDT -0400 due to DST. Now your system will say the event is at 7pm local time. YOU just rescheduled the event. Works the same with dates and not just times. If you store each of those events individually and the politicians move the DST switch date (or an error was corrected in the TZ database) then some of your event times will now be an hour off.
        feld 11y ago
        The event was literally moved to a different time UTC. I'm glad we agreed that it was rescheduled. UTC is still the correct way to store it if you want it to be timezone-aware. If every event a specific application needs to be at local time regardless of what the timezone is, stop storing any reference to a timezone.
        Avernar 11y ago
        We don't agree. It was not rescheduled in reality. Your system would have said it was rescheduled to 7pm Toronto time while in reality the event would still be 6pm Tronto time. The people using your site/app/whatever would be an hour late. UTC is the correct was to store timestamps (things that happened) and intervals (things that need to happen x seconds/minutes/hours from now). For future events at a specific geographical location you need to store it as local time + timezone. Many databases have a time+timezone type.
        halostatue 11y ago
        I would go as far to say that the timezone stored should be a named, geographically-based timezone (e.g., America/New York or Canada/Eastern) as opposed to a timezone offset. (If you store the timezone as EDT or EST, you have still encoded -0400 or -0500.)
laut 11y ago
Did you read the article? If a user wants to save a local time and you then convert it to UTC and save that instead, then it can in some cases be impossible to later find out what the entered local time was. The users will rightfully expect their time to stay 14:00 Santiago time if they enter 14:00 Santiago time.

by feld 11y ago

Avernar 11y ago

Not for events like shows, movies, work hours, etc. An event starts and stops at a specific local time. If the DST rules change then the UTC version will be wrong but the one stored in local time + TZ will be correct. Intervals should be stored in UTC. If you're supposed to drop the control rods in a reactor in 24 hours you store the time it's supposed to happen in UTC. DST transitions and rule changes would mess this up if stored in local time. Timestamps for logs and files should also always be UTC.

feld 11y ago
UTC is an anchor. It does not change, it is never wrong. Your application or environment may live under different rules because of location but that problem can be solved by the timezone-aware application. If I am scheduling an event at 08:00 and my TZ is -5, the event is at 13:00 UTC. If my timezone changes due to a new law UTC is not wrong; the event is still going to happen at 13:00 UTC! If the event was previously stored as a local time and not UTC the EVENT is wrong! You solve this by handling the TZ conversion elsewhere and making sure it always has the latest rules. Always store in UTC. Your argument makes no sense.
- laut 11y ago
  If the user expects 8:00 local time then it should stay 8:00 local time. That is at least how people would want their applications to work 99% of the time. If someone enters 8:00 and then the software suddenly changes it to something else, that is confusing. If you actually look at what happens when timezone laws change, people continue to anchor to their local times.
  - feld 11y ago
    Congratulations you literally just rescheduled the event. This is not a timezone issue. The date should still be stored as UTC.
    - Avernar 11y ago
      Wrong. Let's say an event is scheduled for 6pm daily in Toronto (EST -0500). You store it as 11pm UTC. Now eventually we switch to EDT -0400 due to DST. Now your system will say the event is at 7pm local time. YOU just rescheduled the event. Works the same with dates and not just times. If you store each of those events individually and the politicians move the DST switch date (or an error was corrected in the TZ database) then some of your event times will now be an hour off.
      - feld 11y ago
        The event was literally moved to a different time UTC. I'm glad we agreed that it was rescheduled. UTC is still the correct way to store it if you want it to be timezone-aware. If every event a specific application needs to be at local time regardless of what the timezone is, stop storing any reference to a timezone.
        Avernar 11y ago
        We don't agree. It was not rescheduled in reality. Your system would have said it was rescheduled to 7pm Toronto time while in reality the event would still be 6pm Tronto time. The people using your site/app/whatever would be an hour late. UTC is the correct was to store timestamps (things that happened) and intervals (things that need to happen x seconds/minutes/hours from now). For future events at a specific geographical location you need to store it as local time + timezone. Many databases have a time+timezone type.
        halostatue 11y ago
        I would go as far to say that the timezone stored should be a named, geographically-based timezone (e.g., America/New York or Canada/Eastern) as opposed to a timezone offset. (If you store the timezone as EDT or EST, you have still encoded -0400 or -0500.)

laut 11y ago

Did you read the article? If a user wants to save a local time and you then convert it to UTC and save that instead, then it can in some cases be impossible to later find out what the entered local time was. The users will rightfully expect their time to stay 14:00 Santiago time if they enter 14:00 Santiago time.