4 ms·

Date/time specification is incredibly hard. However hard you think it is, it's actually a "little" harder.[1] I'd guess that someone formulating their own date

Date/time specification is incredibly hard. However hard you think it is, it's actually a "little" harder.[1] I'd guess that someone formulating their own date/time format is actually evidence that they don't understand what a problem it is and so their format is wrong. [1] https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs https://en.wikipedia.org/wiki/Time_formatting_and_storage_bu...

layer8 5y ago
In the present case the problem is solely related to using whitespace both as a value separator and also within a value, where both “halves” of the value are also valid values in their own right. It would have been similar if they defined a complex-number type whose syntax consists of the real and imaginary part just being separated by whitespace. The issue has nothing to do with the conceptual particularities of date and time.
- joe_the_user 5y ago
  Sure, I'd just offer the fundamental difficulty is date/time is a sum of "trivial" problems like this. That a date by itself and a time by itself can be "moments in time" is just one of many difficulties around date-time. IE, none of the particularities (other examples being the irregularities of legal month/day combinations) seem "conceptual".
  - layer8 5y ago
    The relevant conceptual difficulties are the distinction between calendar dates plus time-of-day on the one hand vs. physical time (number of actual seconds) on the other hand, and the way they relate to each other via time zones, DST and leap seconds. To a lesser degree, also the fact that months have different lengths, and cultural differences like start of the week, week numbers etc., and finally date formatting. Most of these are really conceptually tied to time keeping. How to create an unambiguous syntax really isn’t.
spicybright 5y ago
It doesn't seem worth it to figure out time/date representation at the data layer like this. Rigid definition of time stamps leads to incompatible parsers and risks if you need to update how the timestamp works. Or, store it as a string and deal with it after parsing. The latter one always wins, hence json's popularity. Baking it into the data format isn't going to make people treat timestamps right. Probably will do the opposite, really.

layer8 5y ago

In the present case the problem is solely related to using whitespace both as a value separator and also within a value, where both “halves” of the value are also valid values in their own right. It would have been similar if they defined a complex-number type whose syntax consists of the real and imaginary part just being separated by whitespace. The issue has nothing to do with the conceptual particularities of date and time.

joe_the_user 5y ago
Sure, I'd just offer the fundamental difficulty is date/time is a sum of "trivial" problems like this. That a date by itself and a time by itself can be "moments in time" is just one of many difficulties around date-time. IE, none of the particularities (other examples being the irregularities of legal month/day combinations) seem "conceptual".
- layer8 5y ago
  The relevant conceptual difficulties are the distinction between calendar dates plus time-of-day on the one hand vs. physical time (number of actual seconds) on the other hand, and the way they relate to each other via time zones, DST and leap seconds. To a lesser degree, also the fact that months have different lengths, and cultural differences like start of the week, week numbers etc., and finally date formatting. Most of these are really conceptually tied to time keeping. How to create an unambiguous syntax really isn’t.

spicybright 5y ago

It doesn't seem worth it to figure out time/date representation at the data layer like this. Rigid definition of time stamps leads to incompatible parsers and risks if you need to update how the timestamp works. Or, store it as a string and deal with it after parsing. The latter one always wins, hence json's popularity. Baking it into the data format isn't going to make people treat timestamps right. Probably will do the opposite, really.