2024: Nested CSS 2025: Temporal Once we can style 's HTML/CSS/ECMA will be complete. Thank you for everyone's hard work. Let's focus on interop and PWA apis!
Oh wow, thank you. I didn't know nested CSS was a real thing nowadays.
JavaScript Temporal is coming
401–410 of 416 posts
Re: JavaScript Temporal is coming
#402Earlier quoted context omitted.
Now try it with a constant: console.log(const x = "hello"); Doesn't work.
That's a declaration. That would be cool. Doesn't currently work with let or var either.
I think this is basically assigning values to the window object, similar to updating values in any object.
e.g.
const a = { b: 1 }
console.log(a.b = 2); // logs 2Re: JavaScript Temporal is coming
#403Earlier quoted context omitted.
I would start by arguing that not every website needs to deal with dates and times on the client side. And furthermore, if a website only needs to deal with dates but not times (surprisingly common) it can be done in a few KB of JavaScript—the Gregorian calendar is easy compared to the mess of ever-changing time zones and leap seconds.
I'd argue the opposite: APIs should publish all datetimes as UTC timestamps and only the client should be involved in presenting datetimes in the way best suited to the user experience. I'd also argue that presenting dates in ~0KB of javascript is better and less error-prone than several KB of javascript - it also allows users to see dates in non-Gregorian calendars when they prefer.
I'm afraid you have missed the point. My point is that most of the time you don't need datetimes. You only need dates.
Think about sites like blogs. The user only needs to know on what date a blogpost is published. Likewise for newspapers: we have hundreds of years of paper newspapers where people know on what date an article is published but not at what time. Think about banks. My bank tells me the date of a transaction, not its time. Likewise for brokerages.
Re: JavaScript Temporal is coming
#404Earlier quoted context omitted.
That's a declaration. That would be cool. Doesn't currently work with let or var either.
I think this is basically assigning values to the window object, similar to updating values in any object. e.g. const a = { b: 1 } console.log(a.b = 2); // logs 2
Only if you haven't already declared the variable. e.g.
let x;
console.log(x = 'hello');
Re: JavaScript Temporal is coming
#405Re: JavaScript Temporal is coming
#406Earlier quoted context omitted.
How about something like: Sol3/CA/Toronto I'd also like all 50 state capitols (and possibly also their largest city) to exist as E.G. Sol3/US/WA-Olympia and Sol3/US/WA-Seattle (respectively to the above; I don't know Canadian provinces that well) Sol3 is a prefix for the 3rd planet (starting ordinal 1, but anything in the orbit of Sol can be Sol0) in our solar system. It's also nicely short so easy to type out in com…
Including the state would be odd for the exact reason you demonstrate; a lot of people outside the country don’t know or care, especially with capital cities — who knows what region Ottawa or Canberra are in? Country largely just makes sense to disambiguate cases like the two different cities a few hundred km apart both named Vancouver.
For US cities it would make sense, though the very largest could be argued to also not include that.
Use case: Configure device for customer in another state, OK like the mailing address state 2 letter code is XX what city? Oh there's a choice of two. The one I've heard of is probably the biggest city. Either way, it comes out OK.
What if you don't know what state something is in? Sol3/US/*City should shell expand on command lines.
Re: JavaScript Temporal is coming
#407Earlier 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.
With the "system" proposed in the comment I replied to, at which time will those businesses open in New York? London? Delhi? Tokyo? And why at those times?
What about, say, Amsterdam and Stockholm?
Re: JavaScript Temporal is coming
#408Earlier quoted context omitted.
I'd argue the opposite: APIs should publish all datetimes as UTC timestamps and only the client should be involved in presenting datetimes in the way best suited to the user experience. I'd also argue that presenting dates in ~0KB of javascript is better and less error-prone than several KB of javascript - it also allows users to see dates in non-Gregorian calendars when they prefer.
I'm afraid you have missed the point. My point is that most of the time you don't need datetimes. You only need dates. Think about sites like blogs. The user only needs to know on what date a blogpost is published. Likewise for newspapers: we have hundreds of years of paper newspapers where people know on what date an article is published but not at what time. Think about banks. My bank tells me the date of a transac…
My brokerage gives me the date, time and time zone! From my most recent transation:
01/31/2025 11:35:11 AM.,ESTRe: JavaScript Temporal is coming
#409Earlier quoted context omitted.
> 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). S…
That’s a good point, I didn’t think about that.
Re: JavaScript Temporal is coming
#410Earlier quoted context omitted.
> Converting to UTC is lossy How so? UTC is a constant point in time. The difficulty lies in representing the value correctly, but the point in time is unchanged. Unlike what sibling comment mentioned, if an appointment is scheduled at 1739287704987, the value will be the same regardless of where and when it's accessed from.
Yes, but they're saying that only works for past events. If you book a dentist appointment in the future using a timestamp, but then the tzdb rules change, you'll wind up with an unexpected result. (Because the civil time will be different and people usually book appointments based on civil time.)
Touché. We should have stuck with Swatch Internet Time