search

marnusw / date-fns-tz

Complementary library for date-fns v2 adding IANA time zone support
MIT License
1.01k stars 112 forks source link

Ireland timezone issue #241

Closed s-aleinik closed 1 year ago

s-aleinik commented 1 year ago

Hi!

I use date-fns-tz in a react-native app, together with react-native-localise (to get the timezone value using getTimeZone func). It appears, that returned timezone for Ireland is Eire which is fine according to https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

But trying to format date using zonedTimeToUtc(date, 'Eire'); I've got an Invalid Date. Works fine for 'Europe/Dublin', but it forces me to do some sort of mapping.

Is it possible to adjust timezone values so it will work the same for both Eire and Europe/Dublin?

versions:

date-fns-tz: 2.0.0, react-native-localize: 3.0.0

marnusw commented 1 year ago

No, I'm afraid, only IANA time zone names are supported.

tao-qian commented 11 months ago

This is actually not an uncommon issue on iOS because iPhone defaults to Cupertino timezone (instead of "America/Los_Angeles") which is not IANA time zone.

tao-qian commented 11 months ago

In the case of Cupertino, the value returned by the iOS system would be "US/Pacific".

Apparently this was already discussed in https://github.com/marnusw/date-fns-tz/issues/28. And we ended up implementing the conversion logic ourselves in our code: https://github.com/marnusw/date-fns-tz/issues/28#issuecomment-546645980.

It would be really helpful to just incorporate this "US/Pacific" -> "America/Los_Angeles" as part of the library, or at least provide a more helpful error message than Invalid time value when the timezone is considered invalid. FWIW, the Rails library we are using on the server side was able to parse "US/Pacific" without problem.

marnusw commented 11 months ago

@tao-qian I haven't really had time to focus on this library for a while and it'll be a bit longer still until I can.

On principle I am against including any time zone mappings in this library, because that would go against the goal of this lib and date-fns to keep the contribution to bundle size as small as possible.

That said, if it turns out there are a small number of cases, say 10 or so, which are well known to cause issues as described on this thread for whatever reason, then I imagine it could be considered if other libraries do something similar. If you wish you can look at the way the Rails library handles things, but I suspect they have a different and larger database because it runs server-side where this doesn't matter. A more relevant check might be whether the Luxon JS date library does any internal mapping. When I last checked they didn't, but if that's changed I will consider pulling across their mapping if it's small enough.