Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Can someone who's been following this explain why they're designing a new API instead of merging one of the successful open source APIs into the standard?


Are those open source APIs standardized though? JS and browser standards are a different beast altogether than e.g. date library documentation. They need to write and specify exact behaviour, so that multiple implementations can be written by all relevant parties.


Indeed. For anyone interested in Temporal specifically, they can see the proposal here: https://tc39.es/proposal-temporal/

Here's an example of the specification for computing the duration between two dates: https://tc39.es/proposal-temporal/#sec-temporal-calendardate...

(I picked one of the "simpler" ones. Have fun.)


There are plenty of very popular libraries that are low quality and/or have some major issues, popularity of a package is not necessarily indicative of a perfect design. When you put something into your language standard to be supported for the next 30 years you want to make sure it’s as correct for as many people as possible. “Oh this seems to work fine let’s merge it” is not a high enough bar.

It’s inspired by JodaTime which got “merged” into Java, so you could say they are actually just merging an open source project, it’s just not one of the common JS ones.


Temporal API is far more consequential than what was attempted before. Their proposal for serializing timezones is about to become the de facto standard extension to ISO 8601 (date/time).


It's already the standard! RFC 9557 was approved late last year. https://www.rfc-editor.org/rfc/rfc9557.html


they might be successful but they are still very lacking. Temporal is very complete!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: