161–170 of 284 posts
My playbook for JavaScript dates is.. store in UTC.. exchange only in UTC.. convert to locale date time only in the presentation logic. This has worked well for me enough that Im skeptical of needing anything else
Earlier quoted context omitted.
Having to provide a complete schema of your json everywhere your json gets parsed negates the advantages of json.
Most JSON libraries in typed languages require this for data binding to complex types though.
Earlier quoted context omitted.
All Temporal objects are easily (de)serializable, though. `.toString` and `Temporal.from` work great.
That's not what I mean. Even though it is serializable, it's still not the same when you serialize/deserialize it. For example `JSON.parse(JSON.stringify(Temporal.PlainYearMonth.from({year:2026,month:1}))).subtract({ years: 1})` won't work, because it misses the prototype and is no longer an instance of Temporal.PlainYearMonth. This is problematic if you use tRPC for example.
`devalue.parse(devalue.stringify(Temporal.PlainYearMonth.from({year:2026,month:1}))).subtract({ years: 1})`
I’d like to have interval types for example const D = new Temporal() const t = new Interval({minutes:5}) const v = D.add(t)
Looking at the caniuse results... f*king Safari (and Opera)... https://caniuse.com/temporal
[flagged]
Assuming this isn’t an LLM bot, I don’t see how you ship that bug multiple times. The docs for JS time are pretty minimal and it’s clear it only stores UTC epoch, so why would you assume it can handle “wall clock time” with no other context? It doesn’t matter if it’s python or tsql or JS or perl — you read the docs on the date time impl every time.
Earlier quoted context omitted.
That's really interesting. Although my worry is the freezing having bad effects down the line after the function returns. a = [1, 2] def check_this(arr) raise "doesn't start with 1" unless a.first == 1 end check_this(a) a Now, if you could temporarily freeze, and then unfreeze only the ones you froze, that could be really cool.
> Now, if you could temporarily freeze, and then unfreeze only the ones you froze, that could be really cool. Is that a missing feature in Ruby? You can't have a frozen reference to an object while retaining unfrozen ones in another scope? That's too bad.
Earlier quoted context omitted.
Assuming this isn’t an LLM bot, I don’t see how you ship that bug multiple times. The docs for JS time are pretty minimal and it’s clear it only stores UTC epoch, so why would you assume it can handle “wall clock time” with no other context? It doesn’t matter if it’s python or tsql or JS or perl — you read the docs on the date time impl every time.
Good luck making sure no one ever uses a “yyyy-mm-dd” string to represent a calendar date in a JSON API, then passes the value to the Date constructor, then formats that Date in a browser. It’s an extremely easy mistake to make without very strict conventions around how calendar dates and timestamps are represented across the entire stack.
The 'safe' way that I try to make everyone use for 'wall clock'/'business' dates is 'YYYY-MM-DDT00:00:00' (without the Z) - this unambiguously parses as 'this date in the current timezone' in basically every languages Date type and it's ISO 8601 compliant. However it's still a pain in the ass to keep straight when serializing as the 'default' output is usually a timezone converted UTC string (Z at the end).
A big step in the right direction, but I still don't like the API, here's why: Especially in JavaScript where I often share a lot of code between the client and the server and therefore also transfer data between them, I like to strictly separate data from logic. What i mean by this is that all my data is plain JSON and no class instances or objects that have function properties, so that I can serialize/deserialize i…
This was an intentional design decision. We wanted to make sure all the temporal types could be serialize/deserializable, but as you mentioned, you couldn't implicitly go back to the object you started with as JSON.parse doesn't support that. Instead the onus is on the developer to re-create the correct object they need on the other side. I don't believe this is problematic because if you know you're sending a Date,…