Proposal-temporal: Support HTML serialization/structured clone

[littledan]

@slightlyoff pointed out that Temporal objects should transparently be serialized by HTML, i.e., structured clone, i.e., "just working" round trip in postMessage (including in Node.js worker_threads!), IndexedDB, etc. Supporting this would be a matter of making a PR against HTML analogous to https://github.com/whatwg/html/pull/3480 . I don't think custom calendars or timezones could be serializable (causing a DataCloneError), but the built-in ones should be fine to serialize. No rush to take an action to take right now; we can prepare this PR when this proposal is at (or almost at) Stage 3.

[kaizhu256]

didn't indexeddb refuse to support bigint? temporals would be even a harder sell.

[littledan]

@kaizhu256 IndexedDB supports BigInt as values. As keys, there wasn't sufficient demonstrated interest in use cases. I expect us to follow this pattern for Temporal as well: initially, support Temporal as values (through structured clone), and later possibly as keys (through special IndexedDB-specific support) if there is sufficient interest.

[littledan]

For background: https://github.com/w3c/IndexedDB/pull/231

[kaizhu256]

k thx for clarification

[littledan]

Stage 3 is probably best for this so that implementers are well aware that structured clone is supported when they go about implementing Temporal. This is a straightforward task.

[Ms2ger]

• How do we deal with datetimeish objects with a custom timezone or calendar?
  
  
  
  • Throw?
  
  
  • Serialize the string id and call X.from on the other side?
  
  
• How do we distinguish custom timezone or calendar objects anyway? When using subclassing, they have all the state we'd usually use to distinguish built-ins

[littledan]

For custom tz and calendar: I suggest that we go by internal slots. If they lack the internal slot of the built-in calendar or tz, throw. If they do have the internal slot but also are a subclass with some methods overridden, ignore those changes and just serialize by the id.

[ljharb]

I agree with that ^ but it speaks to the need for subclasses to be able to provide an arbitrary ID, not just a built-in one, otherwise on the other side, subclasses will be of the wrong type.

[littledan]

I don't see how providing an arbitrary ID would make it work... you would still need matching behavior on the other side somehow.

[ljharb]

That's true - so subclasses just aren't effectively serializable?

[littledan]

Right. In general, functions and classes are not serializable.

[ljharb]

Would it be better then for serializing subclasses to throw rather than silently serializing incorrectly?

[littledan]

I'm not really sure of how the details should work out. HTML has some cases where things throw and some where serialization changes a bit. I think we should look at the details and generally follow HTML conventions where possible. If we have a choice point, I agree with preferring throwing, but I consider this lower priority than following conventions.