Linux- Windows Timezone Mapping?

Question

All the Timezone in Windows are displayed in such a way like

(GMT+10:00) Canberra, Melbourne, Sydney,

GMT and Offset and the place. In turn , the Linux is having every timezone as directory mapping in /usr/share/zoneinfo/[Continent]/[Place].

I am in need of mapping every Windows timezone to the Linux timezone for my application. like

(GMT+05:30) Chennai, Kolkata, Mumbai, New Delhi => Asia/Calcutta

Now the problem surface for the International Date Line West which lies between Russia and America. In Windows, its marked by (GMT-12:00) International Date Line West and from various sources I found that in Linux its Etc/GMT+12.

(GMT-12:00) International Date Line West => Etc/GMT+12

also

(GMT+12:00) Coordinated Universal Time+12 => Etc/GMT-12
(GMT-02:00) Coordinated Universal Time-02 => Etc/GMT+2
(GMT-11:00) Coordinated Universal Time-11 => Etc/GMT+11 

This keeps me puzzled and my app works closely with the Timestamp w.r.t UTC and the UTC offset. So this mapping is confusing me and the app.

Can anyone explain why there is a vice versa of -12 and +12 Offset in both for a same place?

Thanks in Advance :)

Answer 1

Unicode.org hosts a mapping as part of the CLDR. You can get to the latest version here. There are also XML versions of the data linked from that page.

You can find example code (in Python) of how to generate a mapping from the XML data here.

Obligatory Time Zone Rant:

Note that whoever implemented the timezone support in Windows was on drugs. I'm not kidding you. Look at the timezone names. Why is Central European time known as "Romance standard Time". Romance? What, because it includes Paris, or? Roman Standard Time could have made sense a it also includes Rome, but Romance!?

Also, in the registry the timezones are not organized under their id. No, they are, insanely, organized under their display name! Since that is localized, it means every timezone will be located under a different key in different translations of Windows!!! So to find the right timezone, you have to look through all the timezone to see which has the correct id.

I have example code of that too here. See the get_win_timezone() function.

I wonder if it is the same guy who designed this that decided that POSIX should reverse the sign on timezones, so that -8 hours mean plus 8 hours. In any case, I'm sure they were smoking something illegal together.

Answer 2

The definitions in the Etc directory are meant to be POSIX style, thus they have their sign reversed from what you would expect. I'm not an expert for POSIX, but as far as I get it, the basic idea was to express timzones by the combination of their local name and the offset to GMT. An example for middle europe (Central European Time / CET):

Europe/Berlin (w/o daylight savings)  equals  GMT+01:00  equals  CET-1

GMT-1 in the Etc directory in fact describes a (fictous) timezone called "GMT" which is one hour ahead of (the real) GMT.

As far as I know, these files are only there to allow you to create (symbolic) links against them, so if you were situated somwhere in middle europe, you would create a link to GMT-1 and call it CET-1.

The best recommendation I can give you is to entirely ignore the Etc directory and use some mapping table from windows timezone names to unix timezone folders/files. Windows timezone info does not only give the offset to GMT, but also knows about Daylight Savings (and when in begins or ends). The same is true for the folders/files in the timezone database, but not for the files in the Etc directory - they give a simple static offset to GMT.

A list of time zones in the tz database can be found in the wikipedia.

Answer 3

If all the files have the signs reversed, then the files you are looking at are forward mapping offsets, while what you are probably more familiar with is reverse mapping offsets.

Windows typically uses the local timezone for the machine's internal time, so it needs timezone files which can translate back to UTC. Linux typically uses UTC as the machine's internal time, so it needs timezone files which can translate to local time.

Since the offsets for the two machines describe complimentary but opposite directions of time, it stands to reason that the time zone files are inversely related to each other. In other words, if you pick up a set of zone files from one, the other set will be negative.