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

301–310 of 416 posts

Re: JavaScript Temporal is coming

#301

Post by burntsushi »

jrochkind1 wrote: post #292
burntsushi wrote: post #278

Earlier quoted context omitted.

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, anyw…

I would need to see the APIs and examples to be able to evaluate it honestly.

(FWIW, I'm the author of a datetime library in Rust called Jiff.)

Re: JavaScript Temporal is coming

#302

Post by phire »

Secretmapper wrote: post #44
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?…

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 (if you can even call it a framework) wasn't created until 2006. I don't think there were even helper libraries.

I mostly remember javascript from dynamicdrive.com, where you would go to find quick snippets of "Dynamic HTML" to copy/paste into your html. Sometimes there were useful things like roll-over menus, but I remember many of them being silly toys, like sparkles that would follow your mouse around the screen, or snow which would slowly cover the page.

Re: JavaScript Temporal is coming

#303

Post by modzu »

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…

dear god i wish we could just end dst already

Re: JavaScript Temporal is coming

#304

Post by foobarchu »

michaelcampbell wrote: post #182
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…

> Otherwise you'll get a bug twice per year due to DST Those of us of a certain age learned long ago never to schedule cron (etc.) jobs in a production environment between 01:00 and 03:00 local time.

Are your production servers configured in something other than UTC, or is there a factor here I'm missing? I've never really seen a good reason for a live server not to be Z'd out

Re: JavaScript Temporal is coming

#305

Post by ppseafield »

moffkalast wrote: post #187
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.

Well assuming this actually sorts it out, which remains to be seen.

Having used the API with a polyfill, it is a bit verbose and may seem a little obtuse at times. However, it allows you to explicitly differentiate between Date, Time, (Plain)DateTime, and ZonedDateTime. I have had to fix plenty of bugs because a datetime in the browser, datetime on the server, and UTC got mixed up at some point, and this API makes that a lot more difficult (and not likely to happen accidentally).

Re: JavaScript Temporal is coming

#306

Post by obbfhjqsxjfqqbx »

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…

[dead]

Re: JavaScript Temporal is coming

#307

Post by pas »

burntsushi wrote: post #300
akoboldfrying wrote: post #293

Earlier quoted context omitted.

>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.

DB store data, app interpret data, user cry, developer eyes already dry.

(there's also https://github.com/mweber26/timestampandtz which is delightfully simple, 33 commits, last one 7 years ago)

Re: JavaScript Temporal is coming

#308

Post by brundolf »

nikeee wrote: post #299

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…

Is there any non-primitive JS type that has non-referential equality for ==?

Re: JavaScript Temporal is coming

#309

Post by tharkun__ »

amiga386 wrote: post #57
tomtomtom777 wrote: post #28

Earlier quoted context omitted.

> It even solves the serialization issue of the difference between a "fixed-offset" timestamp (e.g. 2025-01-01T00:00+02:00) and one in a specific timezone (e.g. Europe/Paris). Could you elaborate on that? What is the issue?

+02:00 is not political. It's an offset from UTC and will be the same offset in the past and future. Europe/Paris is political. It defines that offsets change at certain times of the year, but that could change tomorrow, or the political boundary that the timezone applies to could split such that the person or entity needing a time in their "local" timezone finds another one needs to be picked (see various US states/…

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.

https://mm.icann.org/pipermail/tz/1993-November/009236.html

Re: JavaScript Temporal is coming

#310

Post by [deleted] »

foobarchu wrote: post #304
michaelcampbell wrote: post #182

Earlier quoted context omitted.

> Otherwise you'll get a bug twice per year due to DST Those of us of a certain age learned long ago never to schedule cron (etc.) jobs in a production environment between 01:00 and 03:00 local time.

Are your production servers configured in something other than UTC, or is there a factor here I'm missing? I've never really seen a good reason for a live server not to be Z'd out

[deleted]
Post reply on HN