unsplash / intlc

Compile ICU messages into code. Supports TypeScript and JSX. No runtime.
MIT License
57 stars 3 forks source link

Timezones #146

Open samhh opened 2 years ago

samhh commented 2 years ago

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?

:warning: Is there any way to make this typesafe? The following throws:

new Intl.DateTimeFormat('en-US', { timeZone: 'oops' })

cc @OliverJAsh

OliverJAsh commented 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.DateTimeFormattimeZone 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:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat#timezone

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. 🤔