Open samhh opened 2 years ago
Should it be required if a date is consumed anywhere? If not, should we default to UTC or the user's implicit timezone?
Perhaps we should mirror the API of Intl.DateTimeFormat
—timeZone
is optional. If it's omitted, the browser will default to the user's local time zone. There's no need for us to provide that default.
⚠️ Is there any way to make this typesafe? The following throws:
The only value implementations must recognize is "UTC"; the default is the runtime's default time zone. Implementations may also recognize the time zone names of the IANA time zone database, such as "Asia/Shanghai", "Asia/Kolkata", "America/New_York".
We could try to create a type to represent the time zone names in the IANA time zone database, although according to the documentation, the implementation doesn't have to support these. 🤔
There's a potential React hydration mismatch between timezones on server and client on web anywhere we're using a
date
ortime
type. This is becauseIntl.DateTimeFormat
uses the system timezone if one isn't explicitly provided.We could take an optional metadata object:
Ideally that property is only present if a message actually consumes a date.
It will affect all dates consumed in a message.
This could be provided either as
opts => args => msg
(fp-tsReader
-compatible) or(args, opts) => msg
.Should it be required if a date is consumed anywhere? If not, should we default to UTC or the user's implicit timezone?
:warning: Is there any way to make this typesafe? The following throws:
cc @OliverJAsh