Hacker News Reader

Comment by lhorie | Hacker News Reader

Right, that's because Intl isn't a formatting API, it's an internationalization one. There are expectations in the UK about which order month and day are supposed to appear in a date string, and they differ from the order adopted by various other localizations. For example `01/02/2021` and `1.000` mean very different things in certain parts of the world than they do in the en locale. Matching these types of local expectations given a locale is what Intl is for. It sounds like your client just wants a custom arbitrary format, in which case dayjs is a fine choice.

View on HN

> For example `01/02/2021` and `1.000` mean very different things in certain parts of the world than they do in the en locale.

The date means different things between the various English locales. In most of them, it means 1st February. In the USA, January 2nd.

Unfortunately, the very unusual US format is the default locale in many systems.

Wanting to replace space (" ") with dashes ("-") or slashes ("/") is not an outrageous request. People will understand 2020/02/02 as easily as 2020-02-02 or 2020 02 02. Offering an easy way to replace that character would not have been too hard, instead we're stuck with string replacement or regex to achieve a fairly common operation when it comes to dates.

Why is using string replacement to, well, replace spaces with dashes if one wants a non-standard string format an outrageous request then? Personally, I've been bitten time and time again by non-standard, hard-coded strftime formats. Either show a localized time and let my system decide the format, or use ISO 8601/RFC 3339. If one must have full control over the format, the Date object exposes getters for each component.

Unfortunately, dates can be deceptively messy. Formatting as 2021-01-02 instead of 2021/01/02 may not seem like a big deal, until you try to parse them back. Then this happens:

    const a = new Date("2021/01/02"); // Sat Jan 02 2021 00:00:00 GMT-0800 (Pacific Standard Time)
    const b = new Date("2021-01-02"); // Fri Jan 01 2021 16:00:00 GMT-0800 (Pacific Standard Time)

Date library authors have been bit hard because date parsing is hard, and they thought it would be easier to let the Date constructor do the job... only to find out via bug reports about the nasty obscurities of the date parsing rabbit hole.

That second example is particularly ugly. It assumes the input is UTC, then it quietly converts that Date to your local time zone.

Proper date input usually requires a widget.

The context of the conversation is showing dates, not parsing dates. Obviously I'm not advocating in changing your data model to something that would be harder to parse, I'm advocating providing APIs for easier show the date in a format that you want it to show as.

Yes, as a software person, I understand that. I brought this up because we were veering into "client asked" territory, and that where we see clashes between seemingly innocent real world asks and technology rabbit holes.

Reply on news.ycombinator.com