
The Intl.RelativeTimeFormat API - cryo
https://developers.google.com/web/updates/2018/10/intl-relativetimeformat
======
ape4
I'd rather see a constant symbol like

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

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

~~~
guachesuedehack
I agree.

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

~~~
wongarsu
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](https://github.com/tc39/proposal-intl-relative-time#api)

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

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

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

------
fiter
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?

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

------
lanius
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!

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

------
wongarsu
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)

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

~~~
dbbk
There already are polyfills for it based on the draft spec

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

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

~~~
repsilat
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.)

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

------
tyingq
Perl's Date::Manip does this sort of thing too. Some examples:
[https://manpages.debian.org/jessie/libdate-manip-
perl/Date::...](https://manpages.debian.org/jessie/libdate-manip-
perl/Date::Manip::Examples.3pm.en.html)

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

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

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

~~~
snek
It will be in all browsers.

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

------
hateful
[https://xkcd.com/927/](https://xkcd.com/927/)

