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

191–200 of 416 posts

Re: JavaScript Temporal is coming

#191

Post by AndrewStephens »

taeric wrote: post #154
troupo wrote: post #67

Earlier quoted context omitted.

You've just introduced timezones

It always cracks me up when people think they are proposing a simpler system by ignoring complexity. Is akin to people saying, "why don't we just change the start/end time of schools/businesses instead of changing the clock back?" As if getting companies to agree to when to make a change, and updating all of their documents/signage/etc. would somehow be easier than allowing them to continue to say "open at 8." For th…

Your idea is a lot better than my plan. When I am king of the world, no business or transactions will be allowed to occur on Feb 29th. Instead, every 4th year there would be a nothing day, where nothing happens. So no systems would ever have to deal with leap days or 366 day years.

Re: JavaScript Temporal is coming

#192

Post by Macha »

burntsushi wrote: post #137
vlovich123 wrote: post #129

Earlier quoted context omitted.

I must be misunderstanding what you’re saying. How does Temporal know to reject something serialized from before a rule was changed when the creation time of the serialized representation isn’t encoded? You’re saying in 1760 [Europe/Dublin] would be a different string vs today? A more concrete example is normal time-zone rule changes - `2025-06-20T17:00:00+02[Europe/Dublin]` would represent different instants if Dubl…

Can you check out the Brazil example in the docs I linked? That really should clear everything up. It explains how a datetime in the future gets serialized, but after a DST change, that serialized datetime becomes invalid. The way this works is by looking at offsets. Think of a time zone as a function mapping between civil time and physical time. Or, another way to think about it is a mapping from a civil time to an…

So in my use cases, there's three types of dates that matter:

1. Past dates. These can be stored UTC, and just rendered in the appropriate timezone as a matter of formatting.

2. Future non-human dates: e.g. the next execution time of a job that runs every hour. These can just be UTC

3. Future human dates: I care about the human selected timezone so that events happen on the wall clock time the user expects. The UTC time and UTC offset are meaningless.

So in cases 1 and 2, having a non-UTC date is not required, while for case 3, the only thing that UTC offset is doing is adding information that could be inconsistent or confusing.

e.g. If the concert is on at 2026-01-31T18:00:00[Europe/Dublin] , that's all that matters, whether that ends up being 2026-01-31T18:00:00+00:00 or 2026-01-31T18:00:00+01:00 is unimportant for whether the building is going to be open at the time. So the system failing to give customers on the day of the concert a countdown because `2026-01-31T18:00:00+00:00[Europe/Dublin]` has become inconsistent because e.g. the EU actually did go ahead and abolish DST is suboptimal.

Re: JavaScript Temporal is coming

#193

Post by harrall »

DanielHB wrote: post #46
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?…

Well browser standards were pretty much gimped by microsoft during the IE5/IE6 era, so from 1998 until around 2010 there was no progress on standards and Microsoft was actively trying to prevent web applications from becoming a thing in order to not damage Windows market share. From 2010 until about 2020 I would say the standard committee took hold and they have been quite busy with other things. Since JS is a langua…

Microsoft was MASSIVELY trying to make web applications a thing. They introduced HTML Applications[1] in 1999 (e.g. Electron). In 2001, they added the JavaScript features that let us have Gmail and Google Maps (XMLHttpRequest). They let you rebuild your Windows desktop or any folder as a HTML in Windows 2000/ME. They created a ton of APIs from web components[2] to CSS effects[3] in 1998.

However, when Netscape died, Microsoft did a 180 and went from the leader in promoting the web to the absolute worst obstruction. It seemed like they completely de-funded their IE development team.

[1] https://en.wikipedia.org/wiki/HTML_Application

[2] https://en.wikipedia.org/wiki/HTML_Components

[3] https://learn.microsoft.com/en-us/previous-versions/ms530752... (previously was just filter:)

Re: JavaScript Temporal is coming

#195

Post by bsmth »

Pikamander2 wrote: post #166

> working with dates and times in JavaScript will be hugely simplified > To help you get up to speed, there are over 270 pages of Temporal docs on MDN Not that I'm complaining about extensive documentation, but seeing these two lines juxtaposed doesn't inspire much confidence.

Blog author here, I have to admit I enjoyed your comment. This is because it's mostly reference documentation, so each method of each class has it's own page, for example:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: JavaScript Temporal is coming

#197

Post by Someone1234 »

huskywall wrote: post #184

Oh wow, I was complaining about working with dates in JavaScript around 2010 or so. It only took 15 years to sort this out.

Dates/Times/Calendars, and all the politics therein, is perhaps the second most complex thing computers are asked to do. The first being human languages (UNICODE, LTR Vs. RTL, CTL, Encoding, Sorting/Collation, Normalization, etc).

Everyone agrees that Date in Javascript wasn't very good, but getting agreement over how to solve thousands of legitimately hard problems takes time. My viewpoint is that it is IMPRESSIVE it ONLY took them 15-years to get this far, and I congratulate everyone and all the hard work it took.

Re: JavaScript Temporal is coming

#198

Post by wholinator2 »

taeric wrote: post #154
troupo wrote: post #67

Earlier quoted context omitted.

You've just introduced timezones

It always cracks me up when people think they are proposing a simpler system by ignoring complexity. Is akin to people saying, "why don't we just change the start/end time of schools/businesses instead of changing the clock back?" As if getting companies to agree to when to make a change, and updating all of their documents/signage/etc. would somehow be easier than allowing them to continue to say "open at 8." For th…

Well i mean, why stop there. We could alter the time of every clock every day by milliseconds or seconds, to keep perfect track of the solar timing. Better yet we could just trash the clock all together and decide to care about the things that got done rather than the exact time spent on it. This is probably not sarcasm

Re: JavaScript Temporal is coming

#200

Post by recursive »

halfmatthalfcat wrote: post #102
dkdbejwi383 wrote: post #54

Earlier quoted context omitted.

The one I want is pattern matching ( https://tc39.es/proposal-pattern-matching/ ), which is still at stage 1 so many years away, sadly.

Pattern matching (and expression based assignment, of which idk if there’s a proposal for or not) are two things that would really drive a ton of value.

Assignment is already an expression, no?

    console.log(x = "hello");
Post reply on HN