TimeZoneInfo should have consistent Ids across Windows and Linux

[eerhardt]

AB#1179633

Currently Windows has TimeZoneInfo.Id values like "Pacific Standard Time" and "Eastern Standard Time". But on Linux they are "America/Los_Angeles" and "America/New_York".

We should make these Ids consistent across platforms so the same code can run on both Windows and Linux. Currently if you call TimeZoneInfo.FindSystemTimeZoneById you need to pass in different strings between Windows and Linux.

[Clockwork-Muse]

Some of this is the intention of the System.Time package (among other things).

[mattjohnsonpint]

I think the right thing to do here is to use CLDR mappings (either directly, or via ICU).

AFAIK, all Windows IDs can be mapped to TZDB Ids. This will let current code run on Linux without modification.

We could also map in the other direction, as many TZDB Ids can be mapped back to Windows zones. Though users would have to consider that it might throw an InvalidTimeZoneException for a valid time zone if it's not mapable.

[mattjohnsonpint]

@Clockwork-Muse - Since this particular bit is about platform support for the existing TimeZoneInfo class, it can't go in the System.Time package.

[karelz]

We need formal API proposal.
It will be entangled with all the other TimeZoneInfo issue - will likely be non-trivial API design and implementation.

[manigandham]

Some recent discussion here: https://github.com/dotnet/corefx/issues/11897

Seems like a small external library is best suited based on comments to keep up with changes without affecting system packages.

https://github.com/mj1856/TimeZoneConverter

[svrooij]

Not sure if this is the correct place, but maybe it is even a good idea to just support creating a TimeZoneInfo with the required fields. Just a public constructor maybe? Or a not read-only id....

I'm currently using Ews-api-core to talk to Office 365. And I cannot set the timezone to display correctly. That is because the TimeZoneInfo.Id gets serialised as XML into the soapheader incorrectly and Office 365 expects the Windows ID <typ:TimeZoneDefinition Id="W. Europe Standard Time"/> , but my application is running on Unix and this is serialised to <typ:TimeZoneDefinition Id="Europe/Amsterdam"/>.

[mattjohnsonpint]

@svrooij - Does my TimeZoneConverter library help? If not, can you elaborate for the team as to why? Thanks.

[svrooij]

@mj1856 Thanks for the reply Matt, but that doesn't help. The problem is that the id's on unix are not in the format that Exchange wants. And Exchange uses the offset and the timezone id to set the timezone on appointments. And if the id isn't in the list it recorgnises it just picks a random one with the same offset (and then displays a notice to the user that the appointment is in a different timezone)

[mattjohnsonpint]

Sure. So you call:

string tz = TZConvert.IanaToWindows("Europe/Amsterdam");
// Result:  "W. Europe Standard Time"

Working .net fiddle here

You would do this in your code before you pass the time zone on to exchange.

[mattjohnsonpint]

@svrooij - I found your report at sherlock1982/ews-managed-api#9. They would have to take the dependency on TimeZoneConverter with the above code to make this work seamlessly for you.

[jpenniman]

@eerhardt /@karelz, I'd like to take a stab at a proposal and implementation. This issue (and dotnet/corefx#11897) directly impacts at least 2 of our customers and more as we migrate customer to Core and Linux. Third party packages are a workaround, but doesn't change the fact that TimeZoneInfo isn't truly xplat/portable, since consuming code can't "build once, run anywhere".

Is there a formal API proposal template I should use? Who would I submit it to?