Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timezones #146

Open
samhh opened this issue Jul 1, 2022 · 1 comment
Open

Timezones #146

samhh opened this issue Jul 1, 2022 · 1 comment

Comments

@samhh
Copy link
Contributor

samhh commented Jul 1, 2022

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:

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

cc @OliverJAsh

@OliverJAsh
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants