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

251–260 of 416 posts

Re: JavaScript Temporal is coming

#251

Post by WickyNilliams »

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…

It's so much nicer than what we're used to working with!

I built a set of low-level calendar components for building date/range pickers [0]. In anticipation of Temporal landing in browsers I decided to forgo Date (at least on the surface, I hid it away) and polyfilled the slither of Temporal I needed. When it lands I can just delete a bunch of code. The components come in at less than 10kb already, so I am looking forward to making them even slimmer!

[0] https://wicky.nillia.ms/cally/

Re: JavaScript Temporal is coming

#252

Post by taeric »

tshaddox wrote: post #206
taeric wrote: post #154

Earlier quoted context omitted.

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…

My bank opens at 9am. My pharmacy opens at 8am. The corner cafe opens at 7:30 but is completely closed on Wednesdays. This "complexity," if you want to call it that, requires very little cognitive load, and certainly doesn't require any standardized features to be added to every operating system and programming language standard library.

The complexity I was referencing was having all businesses change by exactly the same amount on a given day. Which happens relatively flawlessly twice a year in much of the world. Just having them be different times for different companies is a completely separate thing.

Re: JavaScript Temporal is coming

#253

Post by taeric »

wholinator2 wrote: post #198
taeric wrote: post #154

Earlier quoted context omitted.

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

If we could easily change the duration of a second, I'd see little argument for why we wouldn't do that. Some of these solutions are easier than others.

Amusingly, these difficulties aren't static, either. Easy to argue that before rail and modern time pieces, what you are talking about is exactly what happened when people were using solar clocks.

Re: JavaScript Temporal is coming

#254

Post by TheAceOfHearts »

crowcroft wrote: post #201
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.

Since this requires state to track should be up to the developer to define how they want to track and respond to changes in timezone? I'm not sure I would want Temporal to have an opinion on how to handle that?

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.

Re: JavaScript Temporal is coming

#255

Post by [deleted] »

mikepurvis wrote: post #233
WorldMaker wrote: post #223

Earlier quoted context omitted.

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…

As a Canadian, I would love for my timezone to be Americas/Toronto or Americas/Canada/Toronto rather than America/Toronto, but that's pretty far down my register of first world problems.

[deleted]

Re: JavaScript Temporal is coming

#256

Post by huskywall »

Someone1234 wrote: post #197
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 i…

Point taken, I realize it's complicated stuff. My gripe with it was more that other exotic features were being implemented while this was being neglected.

Re: JavaScript Temporal is coming

#257

Post by duskwuff »

zackmorris wrote: post #222

Carbon is a similar class in the PHP world that's inherited from DateTime. This gives a good description of how working with mutable timestamps can cause problems, because methods like $newInstance = $instance->addDay() modify the original instance and return it, rather than returning a copy that's a day later: https://carbon.nesbot.com/docs/ So it's best to mostly use CarbonImmutable so that a new instance is always…

> I could see a project using use..as statements and/or aliases in config/app.php (edit: in Laravel) to import CarbonImmutable and Carbon as aliases

This wouldn't work the way you're hoping for. use statements are file-scoped; a use statement in config/app.php would only affect that configuration file, not the entire application.

Re: JavaScript Temporal is coming

#258

Post by jrochkind1 »

burntsushi wrote: post #142
jrochkind1 wrote: post #133

Earlier quoted context omitted.

It does not assume that -- implementing libraries need to -- and do, in practice right now -- implement the rules for jurisdictions change the rules for offsets. That's part of why they are tied to a certain city -- time zone rules are unlikely to bisect a city, although if they did I guess they'd have to deprecate it as a timezone name and use something else! Not sure if this has ever happened. All of this is kept t…

> As well as keeping track of the gregorian correction in (depending on country) October 1582 (skipping over 10 days in the calendar!), when calculating historical intervals. They really do this, already! Which libraries do this? Libraries usually implement proleptic calendars, including Temporal[1], which specifically do not account for shifts like this. And indeed, the Temporal docs even call out this specific exam…

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 locale instead of ISO timezone locales, which is a legacy mistake!)

(I work in archiving cultural history, so probably deal with pre-19th century dates a lot more than the average coder)

update: I was curious what would happen if I gave DateTime a non-existent date...

DateTime.iso8601('1752-09-05', Date::ENGLAND) => invalid date (Date::Error)

it knows! (England skipped some days in September 1752 as part of Gregorian adjustment)

Re: JavaScript Temporal is coming

#259

Post by jrochkind1 »

mason55 wrote: post #158
jrochkind1 wrote: post #133

Earlier quoted context omitted.

It does not assume that -- implementing libraries need to -- and do, in practice right now -- implement the rules for jurisdictions change the rules for offsets. That's part of why they are tied to a certain city -- time zone rules are unlikely to bisect a city, although if they did I guess they'd have to deprecate it as a timezone name and use something else! Not sure if this has ever happened. All of this is kept t…

> That's part of why they are tied to a certain city -- time zone rules are unlikely to bisect a city, although if they did I guess they'd have to deprecate it as a timezone name and use something else! Not sure if this has ever happened. It's actually easier to create this problem than by bisecting a city, and the easier way is even more complex than bisecting a city. You obviously can't put every hamlet, town and v…

Right, I mean that if in 2030 for some odd reason half of Punta Arenas does DST and half does not, then 'America/Punta_Arenas' would not work as a timezone designator anymore! Obviously unlikely, I probably should not have mentioned it.

Re: JavaScript Temporal is coming

#260

Post by JW_00000 »

williamdclt wrote: post #226
Macha wrote: post #178

Earlier quoted context omitted.

Then Europe/Paris will become an alias for Europe/NewNewYork

What if England and Germany fight for France, half the country being occupied by Germany using `Europe/Francefurt` and the other half by England using `Europe/NewNewYork`? Then you can't know for sure how to interpret a "Europe/Paris" date without knowing the exact geographical location

If I understand [1] correctly, two new zones (or one new one and the old one) would be created in that case. E.g. if Strasbourg would be occupied by Germany in 2027, a new Europe/Strasbourg could be created which has the same rules as Europe/Paris until 2026, and the rules of Europe/Berlin as of 2027.

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

--

By the way, I looked up the time zone in Crimea.

> On 29 March 2014, after annexation by Russia, Crimea switched from Eastern European Time (UTC+02:00) to Moscow Time (UTC+04:00 then, subsequently changed to UTC+03:00). [2]

Crimea has its own zone in the IANA database, Europe/Simferopol, which was updated in 2014 (and already existed before, as it already used Moscow time from 1994 to 1997). [3]

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

[3] https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/DS...; https://github.com/eggert/tz/commit/bb203f1bb0b6cd4bb2b08f25...; https://github.com/eggert/tz/blob/bb203f1bb0b6cd4bb2b08f2560...

Post reply on HN