Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript Temporal is coming

developer.mozilla.org

Post reply on HN
Print view View original

361–370 of 416 posts

Re: JavaScript Temporal is coming

#361

Post by AdhemarVandamme »

reshlo wrote: post #354
tharkun__ wrote: post #309

Earlier quoted context omitted.

Even countries that are on UTC don't save you from this. I had no idea until very recently but there is a time that simply never existed in Iceland! Wednesday January 2st 1908 00:00 clocks were turned forward 28 minutes to 00:28. So an entire 28 minutes of time never eexisted in Iceland even thought today they are on UTC year round and one might think they are the best and easiest country to handle timezone wise. htt…

> So an entire 28 minutes of time never eexisted in Iceland even thought today they are on UTC year round Those two facts aren’t connected. At the time that those 28 minutes were skipped, Iceland was using the equivalent of UTC-01:00.

In the same way that an hour is skipped in many places at the beginning of Daylight Saving Time every year (and the offset changes, e.g. from UTC–5 to UTC–4),

on this particular instant, in Iceland, 28 minutes were skipped because Iceland changed from the offset of Reykjavik’s mean solar time, rounded to the nearest minute (UTC–1:28) to the offset of Reykjavik’s mean solar time, rounded to the nearest hour (UTC–1).

So only from that moment on, Iceland was using UTC–1.

Re: JavaScript Temporal is coming

#362

Post by jillesvangurp »

phiresky wrote: post #23

Temporal is great. I've been using it for a while in production using a polyfill [1], and it solves all issues I've encountered with the old Date() API (which is a lot). It clearly takes inspiration from other high-quality time libraries such as chrono in Rust and Joda Time in Java and combines them into a nice API that's pretty comfortable to use. Yes, it is a bit more complex to handle since it separates time into…

Sounds great. I've been working with kotlinx-date time for a few projects on both the JVM and in browsers using kotlin-js. Because this is a multiplaform library that needs to work on multiple platforms it sort of is stuck with the lowest common denominator; which on kotlin-js was the old Date API.

The way this kotlin library works is that it implements a modern API that uses the underlying platform rather than re-implementing a bunch of things. This is mostly not a bad decision but it does have its limitations. One of the limitations is that not all platforms exposes a sane way to e.g. resolve timezones by their name and localize times while taking into account e.g. day light saving. Fixing that basically requires dealing with the time zone database and not all platforms expose that.

I ran into this recently. I managed to work around it as this is something you can dig out of existing browser APIs but it was annoying having to deal with that. Unfortunately there are probably a few more obstacles on other Kotlin platforms.

Re: JavaScript Temporal is coming

#363

Post by AdhemarVandamme »

WorldMaker wrote: post #223
Cthulhu_ wrote: post #69

Earlier quoted context omitted.

I wonder what happens when a timezone ceases to exist, e.g. what if Paris is renamed to New New York after the British take revenge and take over France.

https://www.icann.org/en/blogs/details/how-time-zones-are-co... Hopefully the British would be kind enough to email the TZ DB group at the IANA (tz@iana.org) a couple years in advance of the legislation to change the name so that the group can get started on collecting the DST rules for Europe/NewNewYork. Some people and devices will probably stick to Europe/Paris out of habit and/or resistance to the change, so the…

The prefered canonical name is continent-or-ocean/city-or-small-island because continents and cities are more stable than countries and country names. The America/state/city convention is the exception, not the rule.

Some timezone identifiers have changed, e.g. Asia/Calcutta to Asia/Kolkata in 2008 and Europe/Kiev to Europe/Kyiv in 2022. But the TZ DB maintainers are rather reluctant to make such changes, and require “long-time widespread use of the new city name” in English before deciding so.

The naming conventions for timezone identifiers are written out at https://ftp.iana.org/tz/tzdb-2022b/theory.html#naming

Re: JavaScript Temporal is coming

#364

Post by agos »

culi wrote: post #261
nobleach wrote: post #13

There are quite a few things marinating in the TC39 pot right now. This is one that I wish would ship sooner, rather than later. I do recognize that it takes dev effort (on the part of v8, JSC, and SpiderMonkey engineers) to get the major browsers to support any of these new features. So I truly appreciate all that folks are doing to move the ball forward. The impatient person in me is cheering, "now get Records and…

Even when it does ship it'll probably be another year before enough browsers have updated to safely use it in production. So you'll need a polyfill. Which you can start using today anyways!

are there polyfills for those proposals?

Re: JavaScript Temporal is coming

#365

Post by jillesvangurp »

sesm wrote: post #275
phiresky wrote: post #23

Temporal is great. I've been using it for a while in production using a polyfill [1], and it solves all issues I've encountered with the old Date() API (which is a lot). It clearly takes inspiration from other high-quality time libraries such as chrono in Rust and Joda Time in Java and combines them into a nice API that's pretty comfortable to use. Yes, it is a bit more complex to handle since it separates time into…

> chrono in Rust and Joda Time in Java Those are from different time epochs, by the time Rust 1.0 was released, Java already had this approach implemented in standard library via java.time and didn't need any 3rd party libraries for this.

Java.time basically is based on joda time and aside from slightly different package names is largely the same thing. That happened to more parts of the Java API. The concurrent package also started out as a standalone library.

Joda time has inspired spinoffs on lots of platforms. Including js-joda for the javascript ecosystem. I'm not sure how much the new Temporal approach is based on that but it wouldn't surprise me that that was one of the starting points for the new standard.

Re: JavaScript Temporal is coming

#366

Post by agos »

TheAceOfHearts wrote: post #2

They should add an event to detect when someone changes timezones. That could be another entry in the "falsehoods that programmers believe about time": programmers believe that your timezone is fixed during usage. But in reality there are millions of people moving between timezones every day.

a timezone change event might be a nice idea, but there's no reason it should be inside Temporal

Re: JavaScript Temporal is coming

#367

Post by throwaway2037 »

Each time I see a programming language upgrade its base library to improve date/time handling, they all look eerily similar to the Java open source library JodaTime, which eventually became JSR-310 (essentially the "2.0" version of JodaTime in the Java base library). Does anyone else notice this? Except for leap seconds, I have never seen a real world business problem that I cannot solve with the current Java date/time APIs.

Re: JavaScript Temporal is coming

#368

Post by agos »

phire wrote: post #302
Secretmapper wrote: post #44

Earlier quoted context omitted.

Javascript, for the longest time, was a _slow_ moving target - web browsers themselves had cross browser issues where API X might work on browser A but not on browser B. There were so many bigger issues like that I think that made this not a high priority in the grand scheme of things. I think a good example of this is jQuery - while jQuery is a good tool, a huge part of its usage was the quirks between browsers. Sel…

And for the longest time, nobody even considered javascript to be a serious tool; It was rare for anyone to write more than a hundred lines of javascript. I remember when google introduced gmail in 2004. Suddenly google had done full single-page application in javascript, proving that not only was it possible, but that the resulting user-experience was awesome. At the time, there were no javascript frameworks. Jquery…

excellent point. it took 6 years (!) for Backbone.js, arguably the first Javascript framework, to come out... and the same year AngularJS.

Re: JavaScript Temporal is coming

#369

Post by agos »

mrkeen wrote: post #124
andyjohnson0 wrote: post #25

From TFA: > When JavaScript was created in 1995, the Date object was copied from Java's early, flawed java.util.Date implementation. Java replaced this implementation in 1997, but JavaScript is stuck with the same API for almost 30 years, despite known problems. I'm not a JavaScript or web developer, and I was surprised by the above. Can anyone comment on why the language was stuck with an inadequate api for so long?…

> Java replaced this implementation in 1997 If that date's correct, they replaced it with another flawed implementation. The 'good' one came much later: https://jcp.org/en/jsr/detail?id=310 > What are the forces at work here? I feel like I'm always simultaneously engaged in about 5 HN threads at a time, advocating for some combination of immutability, type-safety, and/or no-nulls. It's basically all I do. By and larg…

and yet on threads about Elixir there seems a lot of people who care – rightly so, immutability it's great and Elixir makes the best out of it. Don't give up the good fight!

Re: JavaScript Temporal is coming

#370

Post by agos »

russellbeattie wrote: post #266
manbitesdog wrote: post #92

I get that the naming Temporal is used for avoiding conflicts with typical time objects like Moment, Datetime, etc. But isn't it a terrible name? At first glance I thought it was some kind of garbage collection control

We're definitely bike-shedding a decision that has already been made, but I agree that it's a horrible name. First, "Temporal" is an adjective , not a noun. It might be related to time, but it doesn't make intuitive sense. But more importantly, choosing an odd name because it has a lower probability of conflicting with old code will just make the language increasingly obscure over time. When they added Promise and Ge…

Boolean is also a built in named after an adjective, and we deal with it just fine :)

Temporal is not "odd", it's just a bit less common in english that many people are used to

Post reply on HN