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

291–300 of 416 posts

Re: JavaScript Temporal is coming

#291

Post by hajile »

scarface_74 wrote: post #141
hajile wrote: post #134

Earlier quoted context omitted.

JS could be an amazing language to work with if they'd just spec out a "use type" subset that uses an actually-sound Hindley-Milner type system on typed parts (verify types at the untyped fringes and throw if they don't match) while disallowing all the bad parts like type coercion or any of the many other footguns in the language.

TypeScript??

Typescript doesn't do ANY of that. It is intentionally unsound. Rather than prevent the crazy from happening, TS gives loads of ways to abuse the worst parts of the language as it slowly expands to be one of the most complex type systems ever created.

Finally, a "use type" with guaranteed type boundaries could offer loads of runtime optimizations and speedups that TS cannot offer (and has no intention of offering).

Re: JavaScript Temporal is coming

#292

Post by jrochkind1 »

burntsushi wrote: post #278
jrochkind1 wrote: post #258

Earlier quoted context omitted.

Ah, I guess not as many as I thought! Ruby DateTime does it, I hadn't realized it was unusual, if it is! Here it is particularly called out in documentation with example taking account that April 23rd 1616 in England was not the same day as April 23rd 1616 in Italy, and DateTime knows that! https://ruby-doc.org/stdlib-2.6.1/libdoc/date/rdoc/DateTime.... (That class however is using weird "Date::ENGLAND" constants for…

Ah yeah, those look like opt-in calendars to me I think. Definitely other datetime libraries do that. They just also require opt-in AFAIK.

Ruby date/time handling is confusing, with too many overlapping classes, developed at different times with odd interfaces and/or semantic edge cases (not unusual on other platforms either), but I believe the things people use as default/recommended standard these days on ruby actually do support gregorian/julian changeover!

But I guess ruby is unusual there! Or I'm wrong.

But good to know most have it as opt-in, anyway!

Re: JavaScript Temporal is coming

#293

Post by akoboldfrying »

burntsushi wrote: post #168
btown wrote: post #159

Earlier quoted context omitted.

https://datatracker.ietf.org/doc/rfc9557/ for folks' reference about the new [] suffix syntax. It's a really well thought out RFC: the offset, the civil time zone name, and a flag for whether that civil time zone is critical information can all be stored, and an inconsistency marked critical MUST be acted upon by the application explicitly, either by rejecting or requesting user interaction. This may seem redundant,…

Yeah the PostgreSQL situation is just utterly appalling. The fact that there is a type called "timestamp with time zone," that specifically calls out the fact that it has a time zone, but actually doesn't have a time zone is absolutely crazytown. > This may seem redundant, but it's really important to answer "what happens if I have a future timestamp stored, and the USA suddenly rejects daylight savings time. Do I ho…

>the fact that it has a time zone, but actually doesn't have a time zone is absolutely crazytown.

It's always seemed reasonable to me. Sure, "TIMESTAMP WITH UTC OFFSET" would be even clearer -- but, as has been pointed out already, there are 2 valid ways you might want to handle time addition/subtraction, and only one of those ways enables addition to be done without pure speculation on what decisions will be made by political entities in the future, and PostgreSQL does it that way.

Re: JavaScript Temporal is coming

#294

Post by [deleted] »

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…

[deleted]

Re: JavaScript Temporal is coming

#295

Post by soheil »

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…

If they had hurried up and released it before LLMs they might have actually saved hundreds of thousands of wasted development hours.

Re: JavaScript Temporal is coming

#296

Post by pspeter3 »

rimunroe wrote: post #245
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…

Records and tuples are unlikely to ever ship, or at least are extremely unlikely to ship with the semantics around equality people want. My understanding is that browser vendors already have pretty strong opposition to introducing new primitives at this point. Reading this thread[1] will give some explanation as to the hiccups with how equality would behave. It sucks, because while I wouldn't have expected BigInt to…

That's a bummer. I wish there was a way to use non primitive objects in Maps & Sets more effectively then. Perhaps a well known Symbol for hashCode or something.

Re: JavaScript Temporal is coming

#297

Post by phire »

WorldMaker wrote: post #235
DanielHB wrote: post #46

Earlier quoted context omitted.

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…

> during the IE5/IE6 era During that era was a peak of browser innovation. IE5 and IE6 contributed a lot of things to web standards. They contributed a bunch of things that web standards eventually rejected too , but that was the risk of innovation at the time. It was the period between IE6's last feature update and IE7's first release where Microsoft declared the browser wars "finished" and disbanded the IE team ent…

I would say the darkest era was after IE7 was released: 2006-2010.

You could see all the new features, you could use them, you could design your site around them. But so many people refused to upgrade, so as a web developer you were forced to do stupid things to make IE6 work.

And it's not like IE7 was that much better. You needed to put effort into making that work too. At least Chrome and Firefox would usually both do the same thing.

Re: JavaScript Temporal is coming

#298

Post by TheAceOfHearts »

crowcroft wrote: post #270
TheAceOfHearts wrote: post #254

Earlier quoted context omitted.

I would expect a timezonechange event to get emitted on the window and that the developer would be responsible for handling it accordingly. This wouldn't require any changes to Temporal.

Right, like the browser/app environment would be responsible for it, and then devs can hook into that if they want to handle it or not?

To be clear, the operating system is responsible for keeping track of timezone changes. Every major OS has a way for applications to be notified when the timezone changes. The major browsers are already hooked into these notifications, so what I'm suggesting is that when that event is received by the browser they should also emit a "timezonechange" event on the window. Any further handling is up to the developer.

Re: JavaScript Temporal is coming

#299

Post by nikeee »

I really like the temporal proposal, except for one thing: they rely on reference equality in comparisons. On other words:

    Temporal.Instant.from('2020-01-01') != Temporal.Instant.from('2020-01-01')
This isnt inherently bad, but it effectively removes the ability to use these objects as Map keys or collecting them in a Set. I know why that decision was made, I'm just sad that this wont be possible. Maybe there will be some version that relies on records and tuples, if these ever make it.

Re: JavaScript Temporal is coming

#300

Post by burntsushi »

akoboldfrying wrote: post #293
burntsushi wrote: post #168

Earlier quoted context omitted.

Yeah the PostgreSQL situation is just utterly appalling. The fact that there is a type called "timestamp with time zone," that specifically calls out the fact that it has a time zone, but actually doesn't have a time zone is absolutely crazytown. > This may seem redundant, but it's really important to answer "what happens if I have a future timestamp stored, and the USA suddenly rejects daylight savings time. Do I ho…

>the fact that it has a time zone, but actually doesn't have a time zone is absolutely crazytown. It's always seemed reasonable to me. Sure, "TIMESTAMP WITH UTC OFFSET" would be even clearer -- but, as has been pointed out already, there are 2 valid ways you might want to handle time addition/subtraction, and only one of those ways enables addition to be done without pure speculation on what decisions will be made by…

But I'm not critizing the behavior. I'm critizing the name.

And it's not even a timestamp with a UTC offset! It's just a Unix timestamp.

If you think the current naming is "reasonable," then we are likely living in two different planes of existence. And no amount of back-and-forth over the Internet is going to help. This is a level of dissonance that requires an in-person discussion in the pub to resolve.

Post reply on HN