Any chance this will get into corefx?

[xied75]

I read that long issue https://github.com/dotnet/corefx/issues/2116

But not sure what would come out of that.

Any progress on this? I'm in need of a TimeZoneInfo that can understand abbreviations.

[mattjohnsonpint]

Sorry, TimeZoneNames is just my personal project. It isn't planned to move into .NET. You can certainly use it directly though.

The only bits for corefx are those in System.Time found in corefxlab, which don't include time zone localization.

When you say "understand abbreviations", could you expand on your requirements? Does TimeZoneNames solve the problem, or are you looking for something else?

[xied75]

Regarding abbrev, I think your library works, nothing extra needed. By chance I read a paragraph in code comments like this:

// Mono and Java allow you to specify timezones by short id (i.e. EST instead of Eastern Standard Time).
// Mono on Windows and the microsoft framewokr on windows do not allow this. This hack is to compensate
// for that and allow you to match 'EST' to 'Eastern Standard Time' by matching the first letter of each
// word to the corresponding character in the short string. Bleh.

So I was wondering if this could be built-in in corefx. Now I understand that one CST could mean millions of things, thus, giving up... (Just curious how Java is brave enough to decide which CST the caller mean? Or it just defaults to everything usa?)

[mattjohnsonpint]

Those comments (from here I think) aren't exactly accurate, and thus the assumptions made in the associated code are going to be incorrect. Particularly, consider that Windows time zone identifiers have lots of variations, and little consistency. Some of them use numbers or symbols in the IDs, which is going to cause problems if you're going to assume you can take the first character of each word.

The only real reason that Java and Mono may have allowed some abbreviations is because historically, standards like RFC822 included a handful of US time zones. The newer standards don't allow for this.

You're absolutely right about ambiguity. CST could be China Standard Time, Cuba Standard Time, or a few others. IST might be India, Ireland, or Israel, etc. There are two lists I refer to often, here and here. Even these are opinionated and not so consistent. Even CLDR and IANA abbreviations are not official, and in some cases they are known to be invented by technical folks to fill a gap rather than being in actual use by real people. See also on my blog: Time Zone Abbreviations

In real-world practice, it is reasonable to use abbreviations for display purposes, such as in a localized time format shown to a user, like "1/2/2016 3:30 PM CST". But never try to actually parse that time zone abbreviation and make it resolve to a particular time zone. At least - don't attempt it without taking into consideration a wide variety of possible abbreviations for a single zone, and having some additional external context like which country is applicable. Just think of it like date ordering - after all, without additional context I can't tell if the above timestamp is January 2nd or February 1st, so why should I assume that it's US Central Standard Time either?

[mattjohnsonpint]

I'll also add that there are only a few abbreviations recognized as zone identifiers by IANA, and these are only there for legacy compatibility purposes. The only ones you should rely on are "GMT" and "UTC".