You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's a potential React hydration mismatch between timezones on server and client on web anywhere we're using a date or time type. This is because Intl.DateTimeFormat uses the system timezone if one isn't explicitly provided.
We could take an optional metadata object:
{timeZone: string}
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-ts Reader-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?
⚠️ Is there any way to make this typesafe? The following throws:
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?
cc @OliverJAsh
The text was updated successfully, but these errors were encountered: