2 ms·

Sure, time zones are real† and therefore developers need to model them correctly. †arbitrary, yes, but real I'm saying something stronger than it often isn't

Sure, time zones are real† and therefore developers need to model them correctly. †arbitrary, yes, but real I'm saying something stronger than it often isn't necessary, I'm saying that storing time zones as part of a time is almost always the wrong thing to do. For example: if your show is broadcast first in Eastern then in Central time, that's one thing. What if it shows in Canada the next day? All of a sudden you really wish you had modeled space separately from time. Even when some event is time-zone-gated, this will correspond to one exact moment in time, and for e.g. server provisioning that instant is what matters. Including a time zone can only lead to missing that instant, it can never help you find it.

HelloNurse 4y ago
If I understand your example correctly, it is about using time zones as a proxy for "regions where a TV show might be broadcast", which is clearly inadequate but because time zones are coarse and unrelated to the actual data of interest, not because broadcasting times are represented with timezones. (There might or might not be a second layer of error: 13:00 central time is the same time as 14:00 eastern time, 1 time zone to the east, and pretending they are different is a horrible abuse)
kstenerud 4y ago
One thing I try to hammer home is that the time zone portion of a time is absolutely NOT to be used for any other purpose than to determine the time value itself. The moment you need that kind of data for other purposes, you should be recording a separate field in addition to the time field. I even added a write-up about time to the spec: https://github.com/kstenerud/concise-encoding/blob/master/ce-structure.md#how-to-record-time https://github.com/kstenerud/concise-encoding/blob/master/ce...
- lifthrasiir 4y ago
  I appreciate your detailed write-up, which I found reasonable (at least for date & time things, I haven't read others), but most users would be clueless about this separation and will write something seemingly works, only to find it broken later. I also have a concern about the implementation complexity [1], which combined with clueless users can have a bigger effect. [1] Back when I designed my own serialization format I criticized TOML's decision to add date and time types for the same reason: https://github.com/lifthrasiir/cson#no-additional-types https://github.com/lifthrasiir/cson#no-additional-types
  - kstenerud 4y ago
    Yes, the time data is complicated, but then again time is by nature hellishly complicated and difficult to get right. If I reduce scope, it just maintains the status quo we have now, which is everyone doing everything in TZ offsets (that's ISO 8601's fault), and doing it very, very wrong the moment they step out of the tiny confines of event timestamps. I know this sounds like an "if everyone would just ..." kind of excuse, but poor time implementations really are a big problem in the industry, and I'm hoping to at least provide the tools for knowledgeable people to do it right.

HelloNurse 4y ago

If I understand your example correctly, it is about using time zones as a proxy for "regions where a TV show might be broadcast", which is clearly inadequate but because time zones are coarse and unrelated to the actual data of interest, not because broadcasting times are represented with timezones. (There might or might not be a second layer of error: 13:00 central time is the same time as 14:00 eastern time, 1 time zone to the east, and pretending they are different is a horrible abuse)

kstenerud 4y ago

One thing I try to hammer home is that the time zone portion of a time is absolutely NOT to be used for any other purpose than to determine the time value itself. The moment you need that kind of data for other purposes, you should be recording a separate field in addition to the time field. I even added a write-up about time to the spec: https://github.com/kstenerud/concise-encoding/blob/master/ce-structure.md#how-to-record-time https://github.com/kstenerud/concise-encoding/blob/master/ce...

lifthrasiir 4y ago
I appreciate your detailed write-up, which I found reasonable (at least for date & time things, I haven't read others), but most users would be clueless about this separation and will write something seemingly works, only to find it broken later. I also have a concern about the implementation complexity [1], which combined with clueless users can have a bigger effect. [1] Back when I designed my own serialization format I criticized TOML's decision to add date and time types for the same reason: https://github.com/lifthrasiir/cson#no-additional-types https://github.com/lifthrasiir/cson#no-additional-types
- kstenerud 4y ago
  Yes, the time data is complicated, but then again time is by nature hellishly complicated and difficult to get right. If I reduce scope, it just maintains the status quo we have now, which is everyone doing everything in TZ offsets (that's ISO 8601's fault), and doing it very, very wrong the moment they step out of the tiny confines of event timestamps. I know this sounds like an "if everyone would just ..." kind of excuse, but poor time implementations really are a big problem in the industry, and I'm hoping to at least provide the tools for knowledgeable people to do it right.