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.
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.
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.
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!
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.
> 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.
> 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.
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.
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?
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 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.
43 comments
[ 3.0 ms ] story [ 88.0 ms ] threadCan't wait until this available in electronjs (sufficient browser support is as always likely to take a while longer)
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.
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.
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.
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!
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...
> 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
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.
Moment.js does it, and I never felt like it wasn't what I wanted: https://momentjs.com/docs/#/displaying/fromnow/
I think a lean api without a lot of business rules is the way to go
Besides, most implementations keep the absolute date format in the alt tooltip if you need it.
(TIL also that "semester" means "six months". I'm an idiot, I thought it was "half-length period". Like "semi" I guess.)