Is there something similar for Python? I only write the occasional script, and the default time functions are just bad.
JavaScript Temporal is coming
381–390 of 416 posts
Re: JavaScript Temporal is coming
#382Earlier quoted context omitted.
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).
What would happen at a call boundary from untyped -> typed and typed -> untyped?
Re: JavaScript Temporal is coming
#383I'm honestly really excited for this to be more widely adopted to the point it can be used without polyfills. While the API is a little verbose for my liking, it's extremely capable.
Being able to replace all the various date and time libraries with something browser-native is a massive win for bundle sizes, as even the most lightweight ones are going to start creeping up there once you're dealing with localisation on top of it.
Re: JavaScript Temporal is coming
#384Earlier 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.
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 command lines.
Every state _should_ have it's own TZ file, even if it's just an alias. That's a good forward compatible way of allowing the same config to work if future legislative efforts produce or remove timezones. It would also allow E.G. Arizona's non DST timezone to remain correctly configured in some future where the US finally ends the nightmare of DST forever.
Re: JavaScript Temporal is coming
#385Earlier quoted context omitted.
That won't save you everywhere, Greenland falls back at midnight (12 AM Sunday to 11 PM Saturday) in order to synchronize their DST change with Europe https://www.timeanddate.com/time/change/greenland/nuuk
I wonder if that will that change when America owns Greenland /s
Have you seen the patchwork that is DST in the US? I don't think the US will bring more consistency to established international standards.
Re: JavaScript Temporal is coming
#386Sounds great!
Just annoyed to use it I have to update all my unit test mocks for Date hahaha...
Re: JavaScript Temporal is coming
#387Earlier quoted context omitted.
The DurationFormatter proposal allows you control over which units you want formatted and at what brevity: eg. 1 yr, 3 hours, and 3m. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... I partially implemented it in the icu4x library.
DurationFormat looks cool but it didn’t behave as I expected. https://github.com/tc39/proposal-intl-duration-format/issues...
As the comment mentions there, the idea is that you can do those sorts of transformations on the duration and then emit them:
>> d = Temporal.Duration.from({milliseconds: 60000})
>> d.seconds
0
>> d.milliseconds
60000
>> d = d.round({largestUnit: 'second'})
>> d.seconds
60
>> d.milliseconds
0Re: JavaScript Temporal is coming
#388Earlier quoted context omitted.
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.
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.
Re: JavaScript Temporal is coming
#389Earlier quoted context omitted.
That only works for past events, not future ones. Converting to UTC is lossy so rendering timestamps correctly in the future becomes problematic with DST/TZ rule changes.
> 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.)
Re: JavaScript Temporal is coming
#390Earlier quoted context omitted.
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…
BigInt shipped because financial organizations needed it for certain applications.
I know why people needed it. It’s obviously useful. However, it’s still a relatively niche use case and rarely encounter people using it, especially compared to how many people I encounter asking about dealing with compound keys in maps or how to deeply compare two static blobs of JSON-style data. I understand why the implementers felt burned by its lack of adoption given its burden of implementation, but I’m also a bit surprised they expected more use.