4 ms·

A post about fixing Date in JavaScript got me thinking about why it took so long for languages to get good date/time APIs. I think it's because it took so long

by twic 7y ago

A post about fixing Date in JavaScript got me thinking about why it took so long for languages to get good date/time APIs. I think it's because it took so long to accept that date and time really is complicated. If you sit down and work it out carefully, you end up with Joda-Time (more or less - not in all the details, but in the set of abstractions). If you balk at that and make something simpler, you make a subtly but fundamentally broken API. It took a long time for us to get comfortable with the level of complexity in Joda-Time, but now nobody thinks a serious date/time API can be substantially simpler. It sounds to me like you and the author are saying that Go does this balking systematically.

alexhutcheson 7y ago
The author of Joda-Time actually thinks that even Joda-Time didn't get it quite right, and believes the java.time libraries in Java 8 and above (aka JSR-310[1]) are better than Joda-Time: https://blog.joda.org/2009/11/why-jsr-310-isn-joda-time_4941.html https://blog.joda.org/2009/11/why-jsr-310-isn-joda-time_4941... It turns out that abstractions for time are really hard to get right. [1] https://jcp.org/en/jsr/detail?id=310 https://jcp.org/en/jsr/detail?id=310
- WalterBright 7y ago
  Date & Time need to be baked into the operating system so it only has to be gotten right once, and then every programming system benefits.
  - dralley 7y ago
    So long as they actually get it "right". Compare to Windows' APIs originally taking UCS-2, then UTF-16, when now we would all rather be using UTF-8.
    - ben509 7y ago
      In fairness to Windows and Java, they weren't wrong. There was no UTF-16, rather, UCS-2 was the accepted standard because the plan for Unicode was to encompass languages in use, not emojis and historical langauges. That changed and we're stuck with that legacy.
      - erik_seaberg 7y ago
        Even without emoji, mashing up Chinese, Japanese, and Korean to fit in 21k was never going to happen. It’s sort of like asking Danes to stop spelling their names correctly because we can't afford the extra codepoint for “å”. https://en.wikipedia.org/wiki/Han_unification#Rationale_and_controversy https://en.wikipedia.org/wiki/Han_unification#Rationale_and_...
        Dylan16807 7y ago
        What I don't understand is how they miscounted so badly. Even ignoring Han unification, Chinese by itself uses more than 65k. Or was there an intent to not encode some of these rarer characters? I haven't been able to find any info.
        Tuna-Fish 7y ago
        They didn't think they knew enough about CJKV to make that call, and so instead asked pre-eminent scholars from major Chinese, Japanese and Korean universities, and they replied that 21k was going to be enough. The reason they thought that they could fit Chinese into so few letters was that at the time, the CPC supported academics who wanted to reform Chinese towards fewer letters. Not long after, views about traditional scholarship changed, and now they want to promote maintaining more of their traditional characters. The reason they thought Han unification would work was that the time they asked was in a short period of rapprochement in Sino-Japanese relations. At the time, it was good politics for Chinese scholars to co-operate with Japanese ones. Very soon after this changed.
        Dylan16807 7y ago
    - jonchang 7y ago
      Note that UTF-8 hadn't actually been invented at the time UCS-2 was implemented in Windows: https://unascribed.com/b/2019-08-02-the-tragedy-of-ucs2.html https://unascribed.com/b/2019-08-02-the-tragedy-of-ucs2.html
  - rictic 7y ago
    How much does that actually help? Some things are much easier when system calls return sane values, but the standard library of a programming language needs to work as best it can on many platforms.
  - mntmoss 7y ago
    That solves the problem for one computer, but I can't see how it would solve it for networks and databases, given a computing environment that will continue to evolve and foil compatibility. But a time protocol that recieves the wide adoption of TCP/IP might suffice.
- dehrmann 7y ago
  Props to him for not having an ego with that. Jodatime even recommends using JSR-310 time for new development.
  - nogridbag 7y ago
    The author of Joda was the primary person responsible for the new Java Date and Time API (JSR-310).
rapind 7y ago
IMO taking some time to deeply understand typical date / time abstractions is almost as useful as learning SQL, basic algos, and git. It'll keep coming up throughout your career and inevitably bite you in the ass.
agumonkey 7y ago
for js I can understand, based on history it wasn't meant to do much.. so they put a trivial model Java on the other hand is a lot more surprising.. but maybe they expected to be a third party package from the get go..
int_19h 7y ago
Strings are the same story, except there's still a widespread (and incorrect) perception that they're simple - probably because it's a built-in type in almost every language.

by twic 7y ago

alexhutcheson 7y ago

The author of Joda-Time actually thinks that even Joda-Time didn't get it quite right, and believes the java.time libraries in Java 8 and above (aka JSR-310[1]) are better than Joda-Time: https://blog.joda.org/2009/11/why-jsr-310-isn-joda-time_4941.html https://blog.joda.org/2009/11/why-jsr-310-isn-joda-time_4941... It turns out that abstractions for time are really hard to get right. [1] https://jcp.org/en/jsr/detail?id=310 https://jcp.org/en/jsr/detail?id=310

WalterBright 7y ago
Date & Time need to be baked into the operating system so it only has to be gotten right once, and then every programming system benefits.
- dralley 7y ago
  So long as they actually get it "right". Compare to Windows' APIs originally taking UCS-2, then UTF-16, when now we would all rather be using UTF-8.
  - ben509 7y ago
    In fairness to Windows and Java, they weren't wrong. There was no UTF-16, rather, UCS-2 was the accepted standard because the plan for Unicode was to encompass languages in use, not emojis and historical langauges. That changed and we're stuck with that legacy.
    - erik_seaberg 7y ago
      Even without emoji, mashing up Chinese, Japanese, and Korean to fit in 21k was never going to happen. It’s sort of like asking Danes to stop spelling their names correctly because we can't afford the extra codepoint for “å”. https://en.wikipedia.org/wiki/Han_unification#Rationale_and_controversy https://en.wikipedia.org/wiki/Han_unification#Rationale_and_...
      - Dylan16807 7y ago
        What I don't understand is how they miscounted so badly. Even ignoring Han unification, Chinese by itself uses more than 65k. Or was there an intent to not encode some of these rarer characters? I haven't been able to find any info.
        Tuna-Fish 7y ago
        They didn't think they knew enough about CJKV to make that call, and so instead asked pre-eminent scholars from major Chinese, Japanese and Korean universities, and they replied that 21k was going to be enough. The reason they thought that they could fit Chinese into so few letters was that at the time, the CPC supported academics who wanted to reform Chinese towards fewer letters. Not long after, views about traditional scholarship changed, and now they want to promote maintaining more of their traditional characters. The reason they thought Han unification would work was that the time they asked was in a short period of rapprochement in Sino-Japanese relations. At the time, it was good politics for Chinese scholars to co-operate with Japanese ones. Very soon after this changed.
        Dylan16807 7y ago
  - jonchang 7y ago
    Note that UTF-8 hadn't actually been invented at the time UCS-2 was implemented in Windows: https://unascribed.com/b/2019-08-02-the-tragedy-of-ucs2.html https://unascribed.com/b/2019-08-02-the-tragedy-of-ucs2.html
- rictic 7y ago
  How much does that actually help? Some things are much easier when system calls return sane values, but the standard library of a programming language needs to work as best it can on many platforms.
- mntmoss 7y ago
  That solves the problem for one computer, but I can't see how it would solve it for networks and databases, given a computing environment that will continue to evolve and foil compatibility. But a time protocol that recieves the wide adoption of TCP/IP might suffice.
dehrmann 7y ago
Props to him for not having an ego with that. Jodatime even recommends using JSR-310 time for new development.
- nogridbag 7y ago
  The author of Joda was the primary person responsible for the new Java Date and Time API (JSR-310).

rapind 7y ago

IMO taking some time to deeply understand typical date / time abstractions is almost as useful as learning SQL, basic algos, and git. It'll keep coming up throughout your career and inevitably bite you in the ass.

agumonkey 7y ago

for js I can understand, based on history it wasn't meant to do much.. so they put a trivial model Java on the other hand is a lot more surprising.. but maybe they expected to be a third party package from the get go..

int_19h 7y ago

Strings are the same story, except there's still a widespread (and incorrect) perception that they're simple - probably because it's a built-in type in almost every language.