1. 17
  1.  

  2. 10

    This one has me conflicted. On the one hand, I understand this reasoning and agree with it, in the specific case discussed — a local University computing system. I think the author is probably making the right choice for their users.

    On the other hand, I will still almost always recommend people just use UTC because it’s a safe long term default. I’ve worked with multiple companies now where all the servers are still on Pacific Time despite opening many global offices over the years. Many of their users and developers are now doing time zone math anyway, because they don’t all live in California anymore. But now they have the added adventure of daylight savings time! 😉

    Granted, if your whole mission is focused on serving a given locality, like a University, you’re probably safe with local time. But even then… as soon as you look at computers intended for research collaboration, that might go out the window too. I’ve seen plenty of academic HPC systems that eventually have more external users than internal, as they get linked into wider research programs.

    1. 5

      On the other hand, I will still almost always recommend people just use UTC because it’s a safe long term default.

      Anything should be a safe long-term default, as long as you’re consistent or store the corresponding time zone. The problems usually happen when you have something like 2020-05-15 17:56:34 and no idea which TZ that refers to, or need to get the user’s configured TZ (which may change). But if it’s stored as 2020-05-15 17:56:34 +0800 then it’s always safe and easily convertible to whatever timezone.

      IMO “always use UTC” is much better phrased as “always know which TZ a time is”. Using UTC internally everywhere is often a convenient way of doing that, but not always.

      1. 1

        But if it’s stored as 2020-05-15 17:56:34 +0800 then it’s always safe and easily convertible to whatever timezone.

        I think that’s a lucky example, since there’s little daylight savings out that way, but much of the world moves their clocks around, so you might share a DST-offset part of the year with someone when it matters, and you’re using these timestamps specifically for correlation.

        The reason UTC is better is because we know where 0° longitude is and we know they don’t practice daylight savings. Was that the result of a car crash into a telephone pole at almost six o’clock? Time zone doesn’t tell you that in parts of the world, but UTC-reported dates will.

        The reason UTC is worse, of course, is because sometimes people don’t provide UTC dates, and sometimes people confuse the time in London or Greenwich with UTC so their reports are bad, and people rarely make this mistake with local time (as the author points out).

        1. 4

          Won’t a format like that take care of DST? For example in Western Europe it would be +0100 in the winter, and +0200 in the summer.

          1. 2

            Not always. Consider an event in the future planned before a decision to change daylight savings time. It’s still going to open at 9am whatever-is-local- on some given future date.

            1. 2

              Assuming the DST change is communicated clearly and in good enough time to the TZ database maintainers… you’d be surprised how often this is not the case.

              Off the top of my head, I can mention Jordan, Turkey, Armenia, Egypt and Russia announcing changes to their DST change schedules with very short notice.

              My fear is that this will happen in the EU too, considering that most politicians don’t really seem to understand the implications of changing the DST schedule…

              1. 1

                Even with past dates, calculations will only be correct iff a library is using a correct timezone database that includes all change history and is using it correctly. It also may not be the case.

                Using UTC and converting to local time only when needed saves one from a lot of “if’s”.

                1. 2

                  Only if you’re using a format that doesn’t save the UTC offset, right? I don’t see how the interpretation of an ISO-8601 datetime like 2020-05-18T08:42:57+02:00 can change in the future.

                  1. 1

                    It can change if you’re planning to schedule something at 09:00 (AM) on 15 Jun 2022 in Berlin, and the current schedule for DST tells you that Germany will be observing DST at that time.

                    Right now we don’t know what EU countries are going to do with DST - abolish it, and stay on normal time? Abolish it and stay on summer time?

                    If Germany decides to stay on normal time your appointment at 2022-06-15T09:00:00+02:00 will be 1 hour later than expected (which is 9AM CET in this case).

                    1. 2

                      Yeah, that makes sense, but the comment above mine was talking about calculations on past dates.

                      1. 1

                        Sorry, I misinterpreted your comment! Yeah, past dates are generally “safe”.

    2. 2

      I think the real difference is if your users are directly affected or using the servers. AFAIK cks runs services for local people at the university, so there it can make sense.

      If you are a “normal” company, no matter what your product is, your users should be removed enough from interacting with the servers that they would report local time from anywhere in the world anyway. I think the pain of DST can easily be avoided. And in the company where we had servers on 3 continents.. no thank you, UTC was very much perfect for that.

      Or maybe I’m just close to enough to UTC (Germany) that I’ve been doing the mental calculation without problems for 20 years already.