5 ms·

Because people think they want "time since epoch" but they really want ISO8601 because they'd like it to be readable, and oh, btw, durations would be nice, too.

by ben509 6y ago

Because people think they want "time since epoch" but they really want ISO8601 because they'd like it to be readable, and oh, btw, durations would be nice, too. That spec is quite large, and everyone wants different parts of it. And different languages have different and somewhat incompatible support for datetimes. And, worse, people want different behavior for invalid datetimes. So your parser either balloons in size and requirements and its test-suite or restricts it to a handful of cases, at which point for most users, your datetime type is useless. This is why if you have a protocol like JSON that allows you to construct arbitrary types or simply parse strings, you let users figure out how to handle it.

stickfigure 6y ago
Nah. The notion of a "time since arbitrary epoch" is pretty universal, even though it may have a variety of representations. Just pick one, it really doesn't matter which. Actually JavaScript already did pick a representation - milliseconds since 1970. It would be easy and unambiguous to add { "foo": T1606410158672 } to the grammar.
- ben509 6y ago
  And I think nobody does that in a protocol because you're adding extra complexity to get you little more than transmitting a number.
  - dmitriid 6y ago
    You get significantly more than transmitting a number. - You get automatic conversion to/from a known datatype, Timestamp, not to an arbitrary number - You get automatic checks on the validity of this datatype - You can specify exact precision of this datatype (for example, you may want to represent nanoseconds, not milliseconds, since epoch)
dmitriid 6y ago
> And different languages have different and somewhat incompatible support for datetimes. The support for datetimes is irrelevant if the protocol spec specifies how to serialize a date. Converters for languages will appear or already exist. Datetimes is one of the most common data types and yes, everyone ends up "constructing arbitrary types or simply parsing strings and letting users guess how to handle stuff". Remember .NET's handling of datetime? [1] ISO 8601 was published in 1988. You'd think that protocols designed in the 21st century would at least know about it. You don't have to require all of it. A sensible expectation of date and datetime would suffice the vast majority of use cases. [1] https://www.hanselman.com/blog/on-the-nightmare-that-is-json-dates-plus-jsonnet-and-aspnet-web-api https://www.hanselman.com/blog/on-the-nightmare-that-is-json...
- ben509 6y ago
  > The support for datetimes is irrelevant if the protocol spec specifies how to serialize a date. Consider JSON and how numbers are handled right now. Per the spec, it's an arbitrarily long decimal, and some libraries do deserialize it to a BigDecimal class. But many libraries in a chain of processing will treat it as a double, often libraries outside your control. So you can't rely on them preserving any accuracy beyond what a double can handle. Likewise, if you have a complex date-time representation, the spec can require all kinds of detail, but in practice, some of that data will be thrown out. And worse, they won't throw an error, they'll truncate that data quietly.
  - dmitriid 6y ago
    Me: Datetime is one of the most used types beside the primitive ones. Let protocols specify what how it has to be serialized. This will serve as a baseline against which libraries will be measured. It significantly reduces questions on how to represent datetime, and libraries handling this have a significantly reduced space for caveats and errors. You: no-no-no, it won't work, let us make it significantly worse. Let us not specify this, and let everyone specify their own ad-hoc solutions with manual parsing and checks which will fail in every which way imaginable and let people serialise datetimes as `"\/Date(1320825600000-0800)\/"` for all I care because ... ?
graderjs 6y ago
Welcome to the datetime apocalypse
- graderjs 6y ago
  So you here know, this is not a joke, nor a fun exercise. It is a serious project, I made it. I did just have some fun with the README tho ;P ;) xx

by ben509 6y ago

stickfigure 6y ago

Nah. The notion of a "time since arbitrary epoch" is pretty universal, even though it may have a variety of representations. Just pick one, it really doesn't matter which. Actually JavaScript already did pick a representation - milliseconds since 1970. It would be easy and unambiguous to add { "foo": T1606410158672 } to the grammar.

ben509 6y ago
And I think nobody does that in a protocol because you're adding extra complexity to get you little more than transmitting a number.
- dmitriid 6y ago
  You get significantly more than transmitting a number. - You get automatic conversion to/from a known datatype, Timestamp, not to an arbitrary number - You get automatic checks on the validity of this datatype - You can specify exact precision of this datatype (for example, you may want to represent nanoseconds, not milliseconds, since epoch)

dmitriid 6y ago

> And different languages have different and somewhat incompatible support for datetimes. The support for datetimes is irrelevant if the protocol spec specifies how to serialize a date. Converters for languages will appear or already exist. Datetimes is one of the most common data types and yes, everyone ends up "constructing arbitrary types or simply parsing strings and letting users guess how to handle stuff". Remember .NET's handling of datetime? [1] ISO 8601 was published in 1988. You'd think that protocols designed in the 21st century would at least know about it. You don't have to require all of it. A sensible expectation of date and datetime would suffice the vast majority of use cases. [1] https://www.hanselman.com/blog/on-the-nightmare-that-is-json-dates-plus-jsonnet-and-aspnet-web-api https://www.hanselman.com/blog/on-the-nightmare-that-is-json...

ben509 6y ago
> The support for datetimes is irrelevant if the protocol spec specifies how to serialize a date. Consider JSON and how numbers are handled right now. Per the spec, it's an arbitrarily long decimal, and some libraries do deserialize it to a BigDecimal class. But many libraries in a chain of processing will treat it as a double, often libraries outside your control. So you can't rely on them preserving any accuracy beyond what a double can handle. Likewise, if you have a complex date-time representation, the spec can require all kinds of detail, but in practice, some of that data will be thrown out. And worse, they won't throw an error, they'll truncate that data quietly.
- dmitriid 6y ago
  Me: Datetime is one of the most used types beside the primitive ones. Let protocols specify what how it has to be serialized. This will serve as a baseline against which libraries will be measured. It significantly reduces questions on how to represent datetime, and libraries handling this have a significantly reduced space for caveats and errors. You: no-no-no, it won't work, let us make it significantly worse. Let us not specify this, and let everyone specify their own ad-hoc solutions with manual parsing and checks which will fail in every which way imaginable and let people serialise datetimes as `"\/Date(1320825600000-0800)\/"` for all I care because ... ?

graderjs 6y ago

Welcome to the datetime apocalypse

graderjs 6y ago
So you here know, this is not a joke, nor a fun exercise. It is a serious project, I made it. I did just have some fun with the README tho ;P ;) xx