It's a pretty good API. I recently built an appointment booking form and used Temporal for it. Thankfully, all the date logic is server-side (in server-side actions on an Astro site) so I didn't have to worry about browser compatibility.
I just have a few small nitpicks, but they're pretty easily fixable by using my own classes that extend the standard Temporal ones, or just standalone functions. Some examples:
I wish the classes like Date, DateTime, ZonedDateTime, etc had methods like isBefore and isAfter to compare to another instance. For some reason, I can never remember whether compare returning a negative number means the first argument is less than or greater than the second one. Maybe one day we'll get operator overloading.
I wish there was a way to set the default calendar. I had to manually pass calendar: 'gregory' in a bunch of places because I ended up hitting issues without it (one example). My code isn't running outside of areas that use the Gregorian calendar, so setting it as a default in my code would be ideal.
Node support was a bit rough in June/July so I ended up using the polyfill, but I think they've fixed all the major issues now.
That's what Unix time is... kind of. It's what's usually referred to as an "instant", which is a moment in time that's independent of any timezone or calendar. It's just a plain number that increments by 1 every second.
A lot of systems already store dates and times as Unix timestamps, which means they're already timezone-independent and the timezone and formatting are only applied when rendering it.
In some cases, you do actually need to know the timezone. Calendar events are a good example - an event may end in a different timezone than it starts in (like if the event involves travelling), so both timestamps need their own timezone.
There's also cases where there's no 1:1 mapping between a date/time and a Unix time. Daylight saving is the best example. When the clock moves forward from 2am to 3am, the times between 2am and 3am don't have a Unix time, because they don't actually exist. Conversely, when the clock moves from 2am back to 1am, the times between 1am and 2am have two Unix times - one before the change and one after the change.
That's not to mention outliers like Antarctica where each research base chooses its own timezone.
3 Comments
dan@upvote.au · 5 pts · 5d
It's a pretty good API. I recently built an appointment booking form and used Temporal for it. Thankfully, all the date logic is server-side (in server-side actions on an Astro site) so I didn't have to worry about browser compatibility.
I just have a few small nitpicks, but they're pretty easily fixable by using my own classes that extend the standard Temporal ones, or just standalone functions. Some examples:
isBeforeandisAfterto compare to another instance. For some reason, I can never remember whethercomparereturning a negative number means the first argument is less than or greater than the second one. Maybe one day we'll get operator overloading.calendar: 'gregory'in a bunch of places because I ended up hitting issues without it (one example). My code isn't running outside of areas that use the Gregorian calendar, so setting it as a default in my code would be ideal.Node support was a bit rough in June/July so I ended up using the polyfill, but I think they've fixed all the major issues now.
BrianTheeBiscuiteer@lemmy.world · 4 pts · 5d
Not that it fixes everything but we'd have fewer ulcers in the world if we just stored every date in UTC and only converted when a human looks at it.
dan@upvote.au · 3 pts · 4d
That's what Unix time is... kind of. It's what's usually referred to as an "instant", which is a moment in time that's independent of any timezone or calendar. It's just a plain number that increments by 1 every second.
A lot of systems already store dates and times as Unix timestamps, which means they're already timezone-independent and the timezone and formatting are only applied when rendering it.
In some cases, you do actually need to know the timezone. Calendar events are a good example - an event may end in a different timezone than it starts in (like if the event involves travelling), so both timestamps need their own timezone.
There's also cases where there's no 1:1 mapping between a date/time and a Unix time. Daylight saving is the best example. When the clock moves forward from 2am to 3am, the times between 2am and 3am don't have a Unix time, because they don't actually exist. Conversely, when the clock moves from 2am back to 1am, the times between 1am and 2am have two Unix times - one before the change and one after the change.
That's not to mention outliers like Antarctica where each research base chooses its own timezone.
Dates and times are very complicated :)