3 ms·

I look at the arguments in this post and see echoes of Y2K: - It's a clever hack based on an assumption that dismisses the fact that this assumption can change

I look at the arguments in this post and see echoes of Y2K: - It's a clever hack based on an assumption that dismisses the fact that this assumption can change (that the time zone will never be changed, or that everyone will follow the same rules once it does). - The argument for doing it is: It "uses less space" and "takes less time" These are similar to the reasons why we used 2-digit years for so long. Timestamps without time zone data are BUGS (and I mean REAL time zones, not time offsets like CET and PST). They are landmines just waiting to go off once the assumptions they're based upon change. They require your host system to be configured just-so, making your software brittle. They push the ugly details of handling many time issues that could be handled centrally into the user-space (and even worse, they make it OPTIONAL). The Python maintainers are right to remove this, and really they should have removed naive datetime when they released Python 3. Time is one of the most notoriously difficult things to get right. I've yet to see software using time calculations (or anything more complex than recording timestamps of past events - the only thing for which UTC is useful) that is bug-free. Time data ALWAYS REQUIRES time zone data. The only "exception" is timestamps of past events, but only because we always assume them to be UTC (and so there's an implied time zone so long as nobody bucks the trend).

globular-toast 3y ago
Not quite. Local time is very important. "Tomorrow at 9:00" is a meaningful local time for everyone, but doesn't refer to the same global time. It would be wrong to attach a time zone to such data. Past events, on the other hand, do require timezone data if they are recording human activity, which is basically everything. "Just use UTC" is data loss. You now don't know whether at event took place at midday or midnight. Two very different results for many activities.
- kstenerud 3y ago
  "Local time" is time zone metadata. I've written a fair bit about timekeeping, because the context of what you're capturing becomes very important: https://github.com/kstenerud/concise-encoding/blob/master/ce-structure.md#appendix-b-recording-time https://github.com/kstenerud/concise-encoding/blob/master/ce...
  - globular-toast 3y ago
    Imagine you have users all around the world and you've got logs of their activities. Someone asks "do users spend more time on X in the morning or afternoon"? If you only recorded absolute times and threw away their local time then you can't answer that question. It doesn't matter whether you record UTC or local time as long as you record their time zone, you can always derive one from the other. This is an implementation detail that should be abstracted by any decent time library.
    - kstenerud 3y ago
      If you need that kind of information, you should be recording it separately.

globular-toast 3y ago

Not quite. Local time is very important. "Tomorrow at 9:00" is a meaningful local time for everyone, but doesn't refer to the same global time. It would be wrong to attach a time zone to such data. Past events, on the other hand, do require timezone data if they are recording human activity, which is basically everything. "Just use UTC" is data loss. You now don't know whether at event took place at midday or midnight. Two very different results for many activities.

kstenerud 3y ago
"Local time" is time zone metadata. I've written a fair bit about timekeeping, because the context of what you're capturing becomes very important: https://github.com/kstenerud/concise-encoding/blob/master/ce-structure.md#appendix-b-recording-time https://github.com/kstenerud/concise-encoding/blob/master/ce...
- globular-toast 3y ago
  Imagine you have users all around the world and you've got logs of their activities. Someone asks "do users spend more time on X in the morning or afternoon"? If you only recorded absolute times and threw away their local time then you can't answer that question. It doesn't matter whether you record UTC or local time as long as you record their time zone, you can always derive one from the other. This is an implementation detail that should be abstracted by any decent time library.
  - kstenerud 3y ago
    If you need that kind of information, you should be recording it separately.