1. 10
  1.  

  2. 8

    My rule of thumb is: timestamps in the past get stored as UTC, because they happened at a very specific moment of time, which we can represent unambiguously. On the other hand, timestamps in the future (schedules, etc.) get stored as a local time + Olson timezone name, because future timezone updates might change the UTC mapping unpredictably.

    1. 1

      Its too bad the entire world can’t just use UTC time instead of having time zones. I think it might make a lot of things easier as we become more global.

      1. 9

        I imagine most people like going to lunch on Tuesday and not finding out it’s Wednesday when they return. People always focus on the numbers, which are kind of arbitrary, but ignore day breaks. Just take a walk around and see how many “street cleaning on tuesdays” signs you’d need to edit.

        1. 4

          “Sorry, I forgot the working day starts at 03:00 where you live. It’s pretty dark around here at that hour.”

        2. 1

          Just imagine the confusion if/when we ever start adding in times from other moons/planets with regularity. We’re probably going to need to use something like TAI, in addition to localized Earth, Lunar, and Martian (for instance) timezones.

          1. 1

            For my web apps, I’ve always stored times as UTC timestamps on the server, and then let the client (JavaScript) convert it to local time. For a simple web app, I guess that this is perfectly acceptable.

            However, I didn’t know about the Olson database thing. The author is probably right; for any time sensitive application (i.e. where time is critical), it probably makes sense to perform all of those additional steps on the server. However, I’ll certainly not take that advice for granted; this would need heavy testing.