The Intl.RelativeTimeFormat API | Hacker News Reader

The Intl.RelativeTimeFormat API

developers.google.com

81 pointscryo42 comments

I'd rather see a constant symbol like

    rtf.format(3.14, Intl.RelativeTimeFormat.SECOND);

Me too. It seems way "cleaner" that way, not mixing semantics

I agree. This doesn't seem to be a very clean API. It's extremely "stringy".

I agree.

How come?

Quick - is 'seconds' a valid value for the second parameter? You don't know; there's no easy way to know.

If they're constants you can look at all constants available for Intl.RelativeTimeFormat, IDEs can do autocomplete, analysers can check if the value is valid and alert if not. That's just off the top of my head; I imagine there are even more reasons.

TypeScript can check and autocomplete valid values of strings too, but I agree with the other points.

Why not have string "constants" in the library so both methods work?

Hi, I'm the author of the API proposal (together with Rafael and Daniel).

Thanks for feedback!

I understand where your suggestion is coming from, but please, take into account that we are designing the API to fit into the whole ECMA402 Intl API model.

The API we ended up with seems to be more consistent with it than what you suggested. It also allows us to, in the future extend it to compound units more easily.

Saying that, if you have a motivational o help us, come to ecma402 and review our active proposals! We have a bunch such as Intl.Locale, Number first revision, ListFormat etc :) That's a great time to work on the design of them!

Hope that helps!

Agreed. Better to have constants. That way you can quickly know what the available values are.

You could just as well typo the ".SECOND" in the above.

Plenty of existing JS APIs do the stringly thing here, so the proper thing for a checker to do is just check the strings.

Try putting your cursor between the quotes here and hit ctl-space: http://www.typescriptlang.org/play/#src=fetch(%7B%0D%0A%20%2...

That’s not very JavaScript-y. Where else in ECMAScript are constants used like this?

It's nice to see more libraries helping for this kind of things. But looking at the article it seems like the api needs you to pass the language and the unit (days, hours, etc). Does anyone know if there exists an option to not add one? For dynamic values this feature is pretty important. For example, when I post a tweet, I need to see "a few minutes ago" but look at the tweet later, "34563434 minutes ago" is not great. If the developers have to start mapping time values to units (60: 'hours', '24': 'days', etc) that doesn't make the library very useful in a lot of cases.

From the proposal [1]:

> It is the caller's responsibility to handle cut-off logic such as deciding between displaying "in 7 days" or "in 1 week". This API does not support relative dates involving compound units. e.g "in 5 days and 4 hours".

Specifying the locale is optional, and you can specify a list that will be matched against the user agent's preferences.

1: https://github.com/tc39/proposal-intl-relative-time#api

> It is the caller's responsibility to handle cut-off logic such as deciding between displaying "in 7 days" or "in 1 week".

That seems like it'd make the API quite significantly less convenient: it becomes unusable on its own and pretty much has to be wrapped in a helper of some sort.

But the helper can be very thin and doesn't have to ship with massive locale data

adding some simple mapping to decide what to display would not add much size to this lib.

On the other hand there is no obviously right way, and you really need context to decide on the right way to display a duration of 20 days. This way you can write a fairly small wrapper that makes the interesting decisions and leaves the grunt work to the API

In a lot of cases, you don't really. Most cases it is pretty easy to guess what you'd want to show. I'd the say the case where you really want to choose IS the hedge case.

Moment.js does it, and I never felt like it wasn't what I wanted: https://momentjs.com/docs/#/displaying/fromnow/

I expect you'll use a thin wrapper library around this.

I think a lean api without a lot of business rules is the way to go

Does anyone know why this kind of time formatting has caught on? It takes timezones out of the picture, but also results in large rounding and sometimes the need to consult a calendar. Just below this comment box there are many "1 hour ago" references that presumably refer to any time between 1 and 1.499 hours ago -- at least 20% error?

Because it's easier for most people to understand? It's not rocket science.

Besides, most implementations keep the absolute date format in the alt tooltip if you need it.

It depends on context. Sometimes an absolute datetime value is going to be more appropriate, but often relative times are more meaningful and easier to parse (e.g. in this comment thread). Although as others have mentioned, I'd appreciate the full datetime in the title attribute whenever this is used!

I understand the value of relative times, but I wish websites that use these would show the original timestamps as well. That includes you, Hacker News!

A lot of sites use a `title` attribute to hover to see the absolute timestamp. I'm surprised HN doesn't do this.

A very nice API, especially with the inclusion of options like style: 'short' (which produces strings like "in 1 mo.").

Can't wait until this available in electronjs (sufficient browser support is as always likely to take a while longer)

Seems like something that should be fairly easily polyfilled for web usage?

There already are polyfills for it based on the draft spec

> Can't wait until this available in electronjs

Why? Considering the baseline size (both on-disk and in-memory) it's not like relative formatting has much of an impact, unlike genuine websites/web applications.

A bit off-topic, but it seemed perverse that the Spanish word for "quarter" is "trimestre". Turns out that month = mes in spanish, so it's a three-month period, etymologically.

"Trimester" is a word commonly used in English in relation to the stages of pregnancy.

Also in the academic world where there is a quarter year system used (3 trimesters and summer break).

Also some college use it rather than quarter or semester systems.

Mm, and it's good to know it's etymologically closer to "three months" than "third-length period".

(TIL also that "semester" means "six months". I'm an idiot, I thought it was "half-length period". Like "semi" I guess.)

This is so great. I'm looking forward to not having to use bloated js libraries to address date formatting.

Perl's Date::Manip does this sort of thing too. Some examples: https://manpages.debian.org/jessie/libdate-manip-perl/Date::...

I would expect most languages to have something like that available, TFA lists 3 different libraries for Javascript alone.

The point here is not to talk about an innovation, but about the eventuality of an up-to-date, API built into browsers such that eventually it will not be necessary for each and every application to ship and keep updating such a formatting subsystem themselves.

I didn't share it to diminish anything. These libraries that attempt to parse free-form phrases are interesting to compare.

Will that be part of other browsers too or is it a Chrome-only thing?

It will be in all browsers.

I'd rather want to see this (among other stuff) as a part of "ECMAScript standard library" than web browser API.

https://xkcd.com/927/

Reply on news.ycombinator.com