Timezones. So, general rules are:

1. If you don't store timezone, always use and assume UTC. Databases, backends, whatever you use, all time must be kept be in UTC.
2. If you store timezones, ensure you store them everywhere and don't drop them anywhere.
3. It's always better to ignore backend server time in favor of database's `now().` Having a single source of truth makes time consistent (if it's the same database, obviously). If you combine backend time and database time, you likely get a violation of causality.

I've just spent a couple of hours investigating "weird random one-hour time drifts on updates." Guys violated all three rules above:
- they didn't store the timezone;
- their servers had inconsistent timezones. Java was in +XX., while the server itself in UTC. On one host, they forgot to put JVM in the same timezone;
- they dropped the timezone because they thought it was the same everywhere, so there was no point in serializing it.

  • 8
    I've only occasionally bumped into date issues here and there (that is to say nothing crazy, annoying, but not horrible).

    But holy shit Dates are HARD. Coding Blocks had a podcast on dates all by itself and the potential complexity was more than I had ever thought:

  • 22
    This makes me wanna become a flatearther. I could pretend timezones don't exist and through power of denial make all months be 30 days long, all days exactly 24 hours.
  • 11
    Yep, and rule #4:
    - Favor time zone in place of UTC offset.
    Violating it will produce shifts in countries where they always switch one hour behind or ahead.

    Honestly, it COULD be easier, but NO - let's shift ours just because we are special, yay.
  • 2
    Never ask client for their date
  • 2
    @ostream you can pass `-Duser.timezone="UTC"` as a JVM argument: https://docs.oracle.com/javase/9/...
  • 4
    Read this:

    Never. Ever. Play around with time.
  • 4
    Weird deja vu for me reading this, I just spent this morning fixing the same but with PHP 🙈

    It becomes even more fun when you add daylight savings into the equation on top of timezones 😎
  • 3
    I work with time sensitive data so this hits so much harder.

    Just to add to these rules, don't forget the super fun aspect of needing to determine local time from UTC based on the physical location.

    Oh, you don't observe DST?
    Oh, you observe a special DST *sometimes*?
    Oh, you only started/stopped observing DST two years ago which we need to calculate so time doesn't drift for archival reasons?
    Oh, your location overlaps two simultaneous time zones because your zip code is so big?

    Erase time zones forever please.
  • 1
    Sometimes I wonder how WhatsApp handles message date when a user restores their message history from a different timezone. :/
  • 0
    There is also TZ="Europe/Busingen" to change timezones for a command.
  • 1
    Some programming languages make it hard to parse timezones. Python for example. There i need to load the timezone database manual and the i can parse strings. Out of the box Pythons Datetime module is unable to parse any timezone except UTC.
  • 0
    @stop, I still feel some anxiety somewhere in the back of my mind. I used pendulum back in times when I coded in Python.
  • 0
    Always use the servers' time formatted to UTC.
Add Comment