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 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.
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.
Comments
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...
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
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.