Open alejcas opened 4 months ago
Oof, unfortunate that these are used 😬
what would support for windows timezones look like to you, ideally?
Since the translation of windows TZ to IANA tz is incomplete, it won't be possible to do something like ZonedDateTime(..., tz="Romance Standard Time")
The most I can think of would be to have a .tz_windows()
method that translates the IANA tz to a windows one, but I'm struggling to justify such a relatively niche method, which could also be done by defining a mapping. 🤔
In fact it’s just having this mapping into whenever and some helper methods that will convert from one and another (one way unambiguous and the other way just a guess..).
Maybe something to consider for the future.
thanks
I would support this using the injectable TzProvider as I outlined in #65, using a MicrosoftTzProvider
. My understanding is that Microsoft uses its own timezone classification scheme that is different from IANA.
An injectable tzprovider is definitely on the table, albeit with a low priority at the moment.
Hi I like whenever implementation as it address a lot of problems I face when using datetimes.
I would like to see if it fits into whenever to support windows timezones:
See O365 windows timezones support
Windows timezones are horrible in every imaginable situation, but they are used sometimes (mainly outlook).
The problem is that you can get a windows timezone from an Iana one and it's not ambiguos, but not the other way around. It will be a guess:
For example both Romance Standard Time (wtf is romance standard time anyway??) can be "Europe/Paris", "Europe/Madrid", etc..
Thanks