Hacker News Reader

Comment by skeletal88 | Hacker News Reader

One of the downsides of Intl is that there is no way to change the formatting in any sensible way. Our client wanted the date names to be localized to the UK time and date format, but use "-" instead of spaces between date parts. There was no way to do that using Intl, other than replacing spaces with dashes... Or deconstructing the date into parts and composing it into a string by ourselves, but if we have to do that then why use Intl? So we used dayjs for that.

It would be ideal to be able to use localized short and long month names, but be able to format the date and time as required.

Or there should be some other standard library/tool to format dates and times, because the JS ecosystem is a mess. Python is great in that way, that it includes everything needed, and you don't have to reinvent the wheel constantly, or try to find which random library does reinventing the best.

View on HN

We have been talking about this problem a bit. The tension here is that UX mocks a particular locale as "pixel perfect" and doesn't really "care" about how it'll i18n into other locales.

So they want "do the right thing" for 103 out of 104 locales, but "do what I told you" for "MY" locale.

This is a bit of a conundrum because we don't want to treat any locale as "special". To translate it to code you'd write something like:

  if (currentLocale == "THE_ONE_UX_CREATED_MOCKS_FOR") {
    let value = formatToUXProvidedPattern(data);
  } else {
    let value = data.toLocaleString(currentLocale);
  }

I don't have a great answer how to approach it since there are severe drawbacks and risks to all known potential approaches to "squeeze just one particular format that UX provided into i18n database", but I just wanted to say that we're aware that Intl API has the clash with the UX-driven-development.

I think the problem is that design teams don't bake in internationalization when it is not explicitly asked for. It used to be the same thing for responsive pages.

Design tools are also severely lacking here. Even modern tools like Figma have no way to manage copy well (e.g. swap out copy for different "sets" of strings to test the design with variable-length translations). Heck, you can't even use the spell checker or Grammarly on text boxes or comments despite it being a browser-based app.

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.

> 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.

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.

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.

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.

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.

Can't you use formatToParts() to get most of the way there?

Reply on news.ycombinator.com