3 ms·

Time is so often done wrong because we're using a bare number to represent time, and then just assuming what that number actually means. It's like the bad old d

Time is so often done wrong because we're using a bare number to represent time, and then just assuming what that number actually means. It's like the bad old days of text, when you'd get a "string", but you'd have no idea of what encoding it used, so everyone would just assume something. We solved that by settling on UTF-8 for everything - which is fine - but we can't do the same for time, because time zones aren't going away. It's gotten so bad that I've made binary [1] and text [2] formats that handle all cases and have sane defaults (yes, even ISO8601 gets it wrong). A time value without accompanying time zone data is just a bug waiting to happen. Once you add unambiguous timezone information to the time structure, getting correct time information every time is just a matter of making conversion libraries for language X. No more guesswork, no more bugs. [1] https://github.com/kstenerud/compact-time/blob/master/compact-time-specification.md https://github.com/kstenerud/compact-time/blob/master/compac... [2] https://github.com/kstenerud/concise-encoding/blob/master/cte-specification.md#temporal-types https://github.com/kstenerud/concise-encoding/blob/master/ct...

unilynx 6y ago
What (defaults) in ISO8601 do you consider wrong?
- kstenerud 6y ago
  Time zone designators can only be represented as value offsets from UTC, which means that it can't refer to an actual location. Time zones change for political reasons all the time, so using ISO8601 for future events becomes buggy. If Germany changes their policy on Daylight Savings, ISO8601 times such as 2021-08-02T09:00:00+0200 will have a 50% chance of suddenly becoming wrong (because they no longer refer to Berlin time). Another problem with ISO8601 is that omitting the time zone info implies floating time rather than UTC time, and this causes no end of bugs in all implementations. When I finally gave up on it, I came up with the following alternative: Time zone data omitted (implies UTC): 2019-01-23/14:08:51.941245 = January 23, 2019, at 14:08:51 and 941245 microseconds, UTC Area/location based timezone: 1985-10-26/01:20:01.105/America/Los_Angeles = October 26, 1985, at 1:20:01 and 105 milliseconds, Los Angeles time Latitude/longitude based timezone: 5192-11-01/03:00:00/48.86/2.36 = November 1st, 5192, at 3:00:00, at whatever is in the place of Paris at that time
thomasahle 6y ago
> We solved that by settling on UTF-8 for everything - which is fine - but we can't do the same for time, because time zones aren't going away. What the GP is suggesting is exactly doing the same thing for time. If the internal format is always UTC, that doesn't mean timezones are going away for the user, just that they shouldn't show up in the data layer.
- kstenerud 6y ago
  Which is fine for past events, but doesn't solve the issue of future or repeating events. There are actually three main kinds of time: absolute time, fixed time, and floating time [1]. Storing everything in UTC only solves for situations involving absolute time. [1] https://technicalsourcery.net/posts/time-timezones/ https://technicalsourcery.net/posts/time-timezones/
  - fragmede 6y ago
    Which, for anyone that hasn't already seen it, brings us to falsehoods programmers believe about time. https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time https://infiniteundo.com/post/25326999628/falsehoods-program...

unilynx 6y ago

What (defaults) in ISO8601 do you consider wrong?

kstenerud 6y ago
Time zone designators can only be represented as value offsets from UTC, which means that it can't refer to an actual location. Time zones change for political reasons all the time, so using ISO8601 for future events becomes buggy. If Germany changes their policy on Daylight Savings, ISO8601 times such as 2021-08-02T09:00:00+0200 will have a 50% chance of suddenly becoming wrong (because they no longer refer to Berlin time). Another problem with ISO8601 is that omitting the time zone info implies floating time rather than UTC time, and this causes no end of bugs in all implementations. When I finally gave up on it, I came up with the following alternative: Time zone data omitted (implies UTC): 2019-01-23/14:08:51.941245 = January 23, 2019, at 14:08:51 and 941245 microseconds, UTC Area/location based timezone: 1985-10-26/01:20:01.105/America/Los_Angeles = October 26, 1985, at 1:20:01 and 105 milliseconds, Los Angeles time Latitude/longitude based timezone: 5192-11-01/03:00:00/48.86/2.36 = November 1st, 5192, at 3:00:00, at whatever is in the place of Paris at that time

thomasahle 6y ago

> We solved that by settling on UTF-8 for everything - which is fine - but we can't do the same for time, because time zones aren't going away. What the GP is suggesting is exactly doing the same thing for time. If the internal format is always UTC, that doesn't mean timezones are going away for the user, just that they shouldn't show up in the data layer.

kstenerud 6y ago
Which is fine for past events, but doesn't solve the issue of future or repeating events. There are actually three main kinds of time: absolute time, fixed time, and floating time [1]. Storing everything in UTC only solves for situations involving absolute time. [1] https://technicalsourcery.net/posts/time-timezones/ https://technicalsourcery.net/posts/time-timezones/
- fragmede 6y ago
  Which, for anyone that hasn't already seen it, brings us to falsehoods programmers believe about time. https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time https://infiniteundo.com/post/25326999628/falsehoods-program...