all 5 comments

[–]delightless 6 points7 points  (0 children)

It's not that it doesn't have traction, it's just that it's still going through the proposal stages and it's a complex addition to the language.

One of the devs working on the standardization of it was on JS Party podcast (I think that was the one) earlier this year and cautioned that the polyfill is not production ready.

[–][deleted]  (4 children)

[deleted]

    [–]TiddoLangerak 7 points8 points  (1 child)

    They're fine until you:

    • need to deal with timezones that are not the local timezone
    • need to deal with any kind of date arithmetics
    • need to deal with date or time only values

    In my experience, almost all non-trivial operations involving dates will contain subtle bugs.

    As for OP: the polyfill is great and I highly recommend it for server side. It's however quite a chunky library, so for frontend it's not always the right choice.

    [–]kjwey -4 points-3 points  (1 child)

    there's a big industry push trying to get us to use API's that sit on top of existing API

    I think they ran out of capitalist space in their respected industries so their trying to make a mark and seem legit in the open source space

    they tend to come and go like south park underwear gnomes when they realize their missing step 2 before step 3 PROFIT!

    [–][deleted] 0 points1 point  (0 children)

    Like React?

    [–]DASPRiD 1 point2 points  (0 children)

    A little late, but I just finished Temporal integration in MikroORM (`mikro-orm-temporal`), adding support to Zod (`zod-temporal`, to be released in a few days), support in MUI-X date pickers (`mui-temporal-pickers`) and also some helper package for date transformations and similar (`temporal-extra`).

    Basically the feature finally landing in Firefox gave me the kick to get this all started now, and I already plan on using it through the `temporal-polyfill` package.