
Dates and Times in JavaScript – A New API for Dates from TC39 - 98codes
https://blogs.igalia.com/compilers/2020/06/23/dates-and-times-in-javascript/
======
tzs
I'd like to see the JavaScript people, the Java people, the PHP people, the
Perl people, the Python people, the C people, the C++ people, and the people
for every other significant language that supports functions (either directly
or as methods on objects) to get together and once and for all agree on how
the heck we are supposed to deal with times and dates.

Then all of them should implement that in their standard library, so that
going forward we've got one sane conceptual time handling system everywhere.

I tire of dealing with the quirks of everyone having their own approach.

~~~
mattwad
It's not just that. Timezones are the real bugger. Microsoft has their own
list of names separate from the standard IANA timezones, for example. If it
weren't for timezones, IMO dates are pretty damn trivial. It's just a matter
of storing and transferring them properly (in UTC, always!)

~~~
frenchyatwork
Timestamps are damn trivial. When people use dates, that's all they want 90%
of the time. The remaining 10% is where all the hard problems are.

For example, lets say I have a store that opens from 8:00-17:00 every day, and
it's currently 22:00. How long is it till it opens next?

~~~
noja
Three days and an hour more than you think, because it's the weekend, and an
extra day because the public holiday for tomorrow may or not be a working day.
Oh and there was a timezone change.

~~~
aarong11
There was a leap second too, you forgot that one!

~~~
reggieband
People joke, but I worked on a calendar application (well, it was a time
series graph) where a leap second caused a rendering bug.

~~~
yxhuvud
There was this bug in Java related to a leap second that broke all Java
servers in the world one summer..

------
jasonkillian
I think this is a great proposal and a huge step in the right direction for
JS. I am curious though, is there a reason not to just essentially duplicate
the Joda[0]/Java[1]/ThreeTen[2] API? As far as I understand, they are
generally considered a gold standard as far as datetime APIs.

Is it too Java-y that it wouldn't make sense to port to JS? Are there
copyright implications?

The JS Temporal proposal _does_ as far as I can tell, share many of the
underlying fundamental concepts, which is great, but then confusingly has some
types, such as `LocalDateTime`, which mean the exact opposite of what they do
in the well-known Java API [3].

There is still discussion going on about these details, but from my
perspective it seems like the best thing would be to just copy the Java naming
conventions exactly.

[0]: [https://www.joda.org/joda-time/](https://www.joda.org/joda-time/)

[1]:
[https://docs.oracle.com/javase/8/docs/api/java/time/package-...](https://docs.oracle.com/javase/8/docs/api/java/time/package-
summary.html)

[2]: [https://www.threeten.org/](https://www.threeten.org/)

[3]: [https://github.com/tc39/proposal-
temporal/issues/707](https://github.com/tc39/proposal-temporal/issues/707)

~~~
TheCoelacanth
This. They already copied the crappy date API from Java. Why not copy the good
one too?

~~~
eropple
I don't usually laugh at HN comments, but this is pretty good. And it's true.
Joda-Time and its near relatives are just genuinely _good_. So much effort has
gone into addressing so many edge and corner cases that it seems like a shame
to not just tuck all that work under one's arm and steal it.

------
leothekim
So glad to read that the core objects are immutable. This is probably my
biggest gripe of other date/time manipulation libraries, eg moment.js.

~~~
kcorbitt
[https://date-fns.org/](https://date-fns.org/) is the most popular alternative
to moment-js, has an intuitive functional API and treats dates as immutable. I
migrate every project I touch over to it since it has so many fewer footguns.

~~~
eropple
Huh - thanks for the link. The Moment folks also have Luxon, which I've been
using, but there's quite a lot more momentum behind date-fns.

~~~
Drdrdrq
Or give day.js a try. It is basically moment.js without its problems, and
pretty popular too. I tried date-fns but found it cumbersome to use... Ymmv.

------
moralestapia
A comment on the side,

>JavaScript Date is broken in ways that cannot be fixed without breaking the
web.

I really dislike the arrogant tone that many "new" people employ when talking
about some "old" thing they are trying to "improve". (Quotes are there to
indicate sarcasm).

Date is not 'broken', it may just not do whatever the author wishes it did; it
is not 'broken' in the sense of failing to perform its intended function
adequately.

I hope people could change their ways and be a bit more decent in general.

Aside from that, I welcome the new API as I think it would be an improvement
over what we have now.

~~~
ryzokuken
Date is "broken" in that it aged pretty poorly, has a very non-ideal API
surface and exposes developers to a number of footguns, that could, ideally,
be avoided.

The fact that a vanishingly small percentage of JavaScript developers use Date
for non-trivial applications is a great indicator of these failures.

------
pininja
Very excited about the timezone improvements here! Their cookbook has great
examples [https://tc39.es/proposal-
temporal/docs/cookbook.html#preserv...](https://tc39.es/proposal-
temporal/docs/cookbook.html#preserving-local-time)

------
ABoldGambit
Great proposal, but Temporal is a poor name. Why not, in the age of the import
keyword, finally just have a standard library, and import Date from std like a
proper programming language?

~~~
hyperpape
I agree Temporal is an odd name for the object representing an Instant. But it
shouldn't be Date either. A Date does not have a time associated with it.

Java really did a good job here: Instant, LocalDate, LocalDateTime,
ZonedDateTime. (If they hadn't already had java.util.Date, they probably
could've replaced LocalDate/LocalDateTime with Date/DateTime, but that ship
sailed).

~~~
cwp
Temporal is just the namespace. It has classes called DateTime, Date, Time,
TimeZone, Duration etc.

------
oefrha
TL;DR:

Actual spec: [https://tc39.es/proposal-temporal/](https://tc39.es/proposal-
temporal/)

Less formal docs: [https://tc39.es/proposal-
temporal/docs/](https://tc39.es/proposal-temporal/docs/)

Examples: [https://tc39.es/proposal-
temporal/docs/cookbook.html](https://tc39.es/proposal-
temporal/docs/cookbook.html)

You can try Temporal in the JS console on a doc page.

------
renw0rp
And people used to complain about Java development being slow and behind other
languages...

Regarding JavaScript temporals - better late than never I guess.

~~~
ryzokuken
It's been WIP for a few years now! It's easily one of the largest changes to
the stdlib of JavaScript recently, and things like these take forever to
standardize.

------
jeffmcmahan
This is one of those glaring problems that _somehow_ was passed over the last
10 times people got together to decide to improve JS. Remarkable that it has
taken so long.

~~~
ryzokuken
It's been WIP for years now. Just takes a lot of time to standardize something
like this, you know...

------
typescriptfan1
Date is actually pretty good.

* If you're reading UTC dates from the backend and displaying them in local time, new Date(year + 1900, month, day, hour, minute, second) works great.

* It's also easy to calculate repeating intervals in local time by using that constructor with getYear(), getMonth(), etc.

* Send it back to the server with .toISOString(). Add a .replace('Z', '') on that so .NET binds a DateTime with the right Kind.

------
SigmundA
So can I round trip it to JSON yet, no, bummer...

~~~
chrismorgan
JSON has a deliberately limited vocabulary, and is never going to be extended.
Objects, arrays, strings, numbers, booleans and null, that’s all you’re ever
going to get.

------
flipchart
Does this mean I can get rid of moment.js now?

~~~
wyattjoh
I've switched most of my work that used to use moment over to Luxon[0] now.
It's still written by the same authors, but fixes a lot of the drawbacks[1].

[0]:
[https://moment.github.io/luxon/index.html](https://moment.github.io/luxon/index.html)
[1]:
[https://moment.github.io/luxon/docs/manual/moment.html](https://moment.github.io/luxon/docs/manual/moment.html)

~~~
flipchart
I'm using React Widgets[0] and I prefer moment over Globalize (been through so
much pain with this). Maybe it's time to either write a localizer for Luxor or
find a new date time picker

[0]: [https://jquense.github.io/react-
widgets/localization/](https://jquense.github.io/react-widgets/localization/)

~~~
WorldMaker
Depending on your specific needs [0], a lot of date localization can be done
(painfully, but possibly) directly with Browser Intl [1] calls instead of a
library.

[0] Current user's current locale is easy. If for some reason you need to show
some other locale than what the browser is using you'll likely still need
Moment or Globalize.

[1] [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/Intl)

------
noiv
Asking for uni-time ignores physics. It just doesn't exist. It can already be
measured clocks separated by a meter in altitude run differently. We might
have something that works for daily human stuff, but if you leave the planet
or ask for Pico seconds, no standard can help...

~~~
vore
Anyone doing specialized calculations with time at that level of precision is
going to be using specialized code and not any built-in time handling code.

~~~
noiv
That just proves my point, uni-time is a dead end.

------
jchook
Reminds me of the incredible Time on Unix[1] article.

1\. [https://venam.nixers.net/blog/unix/2020/05/02/time-on-
unix.h...](https://venam.nixers.net/blog/unix/2020/05/02/time-on-unix.html)

------
LittleDan
It would be great to hear feedback from everyone on the Temporal survey:
[https://forms.gle/iL9iZg7Y9LvH41Nv8](https://forms.gle/iL9iZg7Y9LvH41Nv8)

------
petepete
So long as months are indexed by 1 I'm all for it.

~~~
ryzokuken
They are!

------
tlhunter
I'm excited to see this land in Node.js! Currently there are only hacky
solutions for calculating nanosecond-accuracy wall clock time.

------
benatkin
I think it's quite nice! It tries to be as unopinionated as possible, and does
a good job at it.

------
sunseb
Why not using a namespace like stdlib/datetime instead of this weird named
Temporal thing?

~~~
ryzokuken
because Temporal is not currently used anywhere (as far as we noticed) and it
won't break anything while still being descriptive.

------
lxe
You will still need libraries to do nicely formatted time strings like "next
week" or "3 hours ago"

~~~
josteink
> You will still need libraries to do nicely formatted time strings like "next
> week" or "3 hours ago"

If you want those formatted values to be consistent with the rest of your app,
you will need this anyway.

You app _does_ support localisation right?

Also: there’s no guarantee a browser would have the same localisation as your
app (for instance German-language browser, English website).

You really have to do this 100% yourself in your app if you want the result to
look right.

~~~
runarberg
Apps are seldomly translated into my native language, but I do have my browser
configured to use my native language, so I often see date values in a
different language from the rest of the app, and it doesn’t bother me at all.
In fact I hardly notice it.

------
himinlomax
Will it allow for using TAI?

~~~
ryzokuken
Not the core API, but a simple custom timezone can be used to implement TAI. I
worked on a POC for it, but you can totally test this with the polyfill right
now.

[https://github.com/ryzokuken/temporal-
tai](https://github.com/ryzokuken/temporal-tai)

~~~
deathanatos
Kind of, but not really? The proposal's Absolute represents time in the POSIX
timescale, so it is inherently incapable of representing all of TAI, the same
as it is inherently incapable of representing UTC.

I attempted to test your library's behavior in this regard, but I do not think
you are correctly implementing the proposal's TimeZone.
TimeZone.getDateTimeFor() is supposed to take an Absolute and return, in your
case, the time that absolute represents in TAI (that time, in the TimeZone).
But this:

    
    
      var one_before = new Temporal.Absolute(915148799n * 1000000000n);
      console.log(one_before.toString());
      console.log((new Temporal.TimeZone('UTC')).getDateTimeFor(one_before).toString());
      console.log((new TAI()).getDateTimeFor(one_before).toString());
    

emits,

    
    
      1998-12-31T23:59:59Z
      1998-12-31T23:59:59
      1970-01-01T00:15:15.148768
    

That last timestamp being the output supposedly in TAI; but that POSIX
timestamp, 915148799 represents 1999-01-01T00:00:30 in TAI. That is, the
second line, 1998-12-31T23:59:59 in UTC == 1999-01-01T00:00:30 TAI.

The other direction (getPossibleAbsolutes) is similarly effected.

------
miltonlaxer
Just gimme epoch time and we're good.

~~~
ryzokuken
Temporal.now.absolute().getEpochNanoseconds()

