Hacker News Reader

Comment by hn_throwaway_99 | Hacker News Reader

It's interesting to me that programming language designers basically always get date/time libraries wrong, and it takes multiple tries to get it right. Just look at the atrociousness of the original java.util.Date and Calendar APIs, and then there was joda-time, and finally that was rolled into the core java.time package. JS is similar, the core JS Date object has many of the same problems as java.util.Date, and so we now have multiple attempts at getting a sane date/time library.

Curious, are there other languages where people feel this date/time mess does not exist?

View on HN

Rust - because it doesn't have date and time in the standard library!

I believe the standard library developers knew date/time was cursed, so punted on it. There is a minimal set of types and functions to allow the bare minimum of system calls etc:

https://doc.rust-lang.org/std/time/index.html

But you have to bring in one of a few crates to do anything else.

chrono is the defacto standard. As with all good modern datetime libs (see also Noda Time, the new java.time), it takes liberal inspiration from Joda Time, which IMO has pretty much set the template for a robust datetime library.

Yep! Most examples in the Rust cookbook[0] use chrono[1].

But note that before Chrono there were other time libraries; one of them was called time[2] - and IIRC it was created from code removed from Rust's stdlib std::time[3]. It eventually proved to be the best decision: designing a good API is a hard effort, and any design was prone to have mistakes and warts.

Chrono provides interoperability with both std::time and the time crate. It acknowledges other datetime crates that it was inspired, like datetime-rs[3] which itself was inspired by Joda time.

[0] https://rust-lang-nursery.github.io/rust-cookbook/datetime.h...

[1] https://crates.io/crates/chrono

[2] https://crates.io/crates/time

[3] https://github.com/depp/datetime-rs

There's an actual joda implementation as well. See https://www.npmjs.com/package/@js-joda/core

At least with this way, you don't have to hang on to bad ideas and specs for eternity. A bad crate can easily be swapped out for a better one and future developers won't have to remember which is the good date functions.

Golang went with the bizarre decision of using a specific timestamp as a template for date format strings. So in Go, instead of having to remember impossible things like "%Y stands for year" and "%H is a two-digit hour", I simply need to recall that the canonical time is Monday, January 2nd 2006 at 15:04:05.

In JavaScript you actually use `Intl.DateTimeFormat`[1] to format datetimes, which takes in a pretty descriptive configuration object with keys such as `month: "short"`, `hour: "2-digit"`, and `hour12: true`.

This is missing in the OP explainer, so I created a PR[2].

1: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

2: https://github.com/you-dont-need/You-Dont-Need-Momentjs/pull...

And it fills a completely different usecase to arbitrary date formats. For one, there's no parsing. And you have to make do with what the browser provides with no guarantee of stability.

To be honest for me it is much easier to memorise %Y and friends then this special date. I feel like this canonical date is easier to write documentation for but harder to use.

Completely agree. It's one of those ideas that seems clever but is a huge pain to use.

I was pretty sure tdeck was being sarcastic, but I might be wrong.

OK, I'm not a Go programmer so was struggling to figure out what was going on, until reading that the "canonical" date for formatting is essentially:

01/02 03:04:05PM '06 -0700

I actually think that's a really good idea. Sure, it may easier to remember "YYYY-MM-DD" than "2006-01-02" at first, but I think it helps a lot in many other cases, e.g. you don't need to remember what is exactly meant by MM and MMM and MMMM, you could just create your format string as "January 2, 2006" or "Jan 2, 2006".

Never realized that, I guess because nobody writes timestamps in "month, day, time, year, zone offset" order.

It’s almost impossible not to get it wrong. Most developers don’t even understand the full scope of the problem (and it’s probably impossible to!).

Even devs with good defensive programming instincts make entirely wrong assumptions because the problem is so vast and complicated. For instance I remember repeatedly explaining to a previous team that we couldn’t treat all of Michigan’s locality outside of its 4 Central Time counties as America/New_York because America/Detroit is governed differently. This was hard to communicate even as I dug up the relatively recent history of TZ changed in MI.

Their eyes collectively glazed over as I tried to explain the complexity of DST in Arizona—the state doesn’t observe DST, most of the reservations do, but some don’t.

I have no idea how library authors are supposed to deal with this. Language authors are more likely to be able to defer to expertise, but even then it’s obviously not going to produce great results. And by and large library authors will depend on the quirks and bugs of the host language.

I agree this is a particular sore spot across the field. I think it’s something that would especially benefit from a cross-environment design.

As in: start with the existing ISO standards, which are good. Determine an appropriate level of abstraction that suits low level platforms, and coordinate higher level abstractions as warranted. I anticipate the XKCD comic, but this is a case where the problem is generally equal-bad for everyone involved and it wouldn’t hurt to try.

haha having had to deal with developer glazeover from DST implications before I suspect we’re not alone. One may accept the inevitable failures that are implicit with the naive date time representation and possibly get a MVP going, but it’s not really more expensive/time consuming to kick the can down the road and hide the inevitable failures behind an interface. The latter requires you to be explicit about the functionality you expect from a date/time value. This means you need a[0] a way to distinguish the type of value it is by the ways you expect to use it...

In data modeling I hide such things behind a foreign key to create a distinct domain. E.g. “PersonBirthDate”, “StartedAt”, “ValidAfter”, “AvailabilityInterval", “FiscalQuarter”, and “ExpiresBy” are all different representations, possibly also distinct by the source entity, and all treated as a distinct domain. Further I’ll often add UDTs and database functions/procedures to help assure integrity (and possibly quality, not always possible of course). Sum Types are unpleasant to model in RDBMS and descendants of such.

[0] a pun, HHOS. <https://en.wikipedia.org/wiki/Yoneda_lemma>

I think the Elixir DateTime API is really clean and well designed. The key was letting libraries explore the problem and surface the right interface, before baking it into the standard library. It does mean it took a long time for this to land but I'd say it was worth it. Learning from the failures of others also certainly helped.

.NET has always had a simple to work with date time API. At least compared to other languages it feels a lot cleaner.

.NET had DataTime which took user's local time zone into account by default. So .NET introduced DateTimeOffset where you can specify time zone.

but by then, DateTime was used in a lot of places, for eg: and .NET Sql Server driver mapped datatime against DateTime (instead of DataTimeOffset)

yeah, .NET has these issues too. and I have not even gone into DateTime Culture!

Rust's Chrono lib is outstanding. Clean API, and works how you expect. This is the only lang I've used that has a good 'default' DT lib. It can compile with `no_std`, ie embedded targets.

Whoever can wrap this in WASM and expose a JS API will be a hero.

JS’s Date is broken because it was based on Java’s broken Date iirc

Reply on news.ycombinator.com