How can I check timezone transition information in windows? In windows I can only find my timezone(in Hong Kong) is "China Standard Time". While I have noticed that in IANA database there is "Asia/Hong_Kong" and some rules for DST in the past:
# Rule NAME FROM TO - IN ON AT SAVE LETTER/S
Rule HK 1946 only - Apr 21 0:00 1:00 S
Rule HK 1946 only - Dec 1 3:30s 0 -
Rule HK 1947 only - Apr 13 3:30s 1:00 S
Rule HK 1947 only - Nov 30 3:30s 0 -
Rule HK 1948 only - May 2 3:30s 1:00 S
I have looked into registry for "China Standard Time" in this answer. It doesn't look like having any of transition information and mapping to "Asia/Hong_Kong".
Thanks a lot for any help!
Historical data in the Windows registry time zone data is only guaranteed from 2010 forward (per note in the table on the Microsoft TZ/DST policy page). There are a few with earlier information, but nowhere going back into the 1940's.
If you want older historical information, you must use IANA time zones, not Windows time zones. Do keep in mind that IANA time zones represent historical time consistently only since 1970, though some time zones have earlier information when available.
As far as how to use IANA data on Windows, that depends very much on which programming language you are working with. There are many different libraries (such as Noda Time for .NET), or you could use the built-in Windows.Globalization.Calendar WinRT/UWP API, or you could use Windows ICU support and one of the ICU ucal_ APIs. If you're specifically interested in the transitions, I recommend NodaTime.
Related
Seems easy but I didn't find a way to convert an UTC datetime to a specified timezone. I found how to convert an UTC date time to local date-time, but now I want to convert to a specific timezone (i.e. for example Moscow time)
For example in c# we can do:
// user-specified time zone
TimeZoneInfo southPole =
TimeZoneInfo.FindSystemTimeZoneById("Antarctica/South Pole Standard Time");
// an UTC DateTime
DateTime utcTime = new DateTime(2007, 07, 12, 06, 32, 00, DateTimeKind.Utc);
// DateTime with offset
DateTimeOffset dateAndOffset =
new DateTimeOffset(utcTime, southPole.GetUtcOffset(utcTime));
Console.WriteLine(dateAndOffset);
But how to do in Delphi ?
A few things:
"Antarctica/South Pole Standard Time" isn't a real time zone identifier. I assume you gave that in jest, but it makes it unclear as to whether you want to use Windows time zone identifiers (like "Eastern Standard Time"), or IANA time zone identifiers (like "America/New_York").
Assuming you want to use Windows identifiers, you can indeed use the functions in the Win32 API. The comment in the question suggested the wrong API however. You should instead use SystemTimeToTzSpecificLocalTimeEx.
It uses the DYNAMIC_TIME_ZONE_INFORMATION structure, which have been available since Windows Vista. To get one of those from a named Windows time zone identifier, use the EnumDynamicTimeZoneInformation function to loop through the system time zones until you find the one matching on the TimeZoneKeyName field.
The "dynamic" structures are important to use, and should always be preferred over their older counterparts. They allow access to changes in time zones and daylight saving time rules that are stored in the Windows registry. Without them, you only get access to the current rule, which might not be the correct rule for the date you are converting.
If you instead wanted to use IANA time zone identifiers, use the Delphi tzdb library, as shown in this post.
If you are uncertain of which to use, I highly recommend this approach. IANA identifiers are inter-operable with other operating systems, programming languages, frameworks, and libraries. (Windows identifiers, less so.)
An IMAP server is sending me timestamps that look like this:
Tue Apr 12 2016 09:45:14 GMT-0500 (CDT)
I've seen this format enough times in enough places to make me think it's standardized. But I don't know what the name of the standard would be.
It's very similar to the RFC 5322 datetime format for emails (my first guess, since I'm working with an IMAP server), but not quite.
Does anyone recognize it?
Edit: Apparently this is the standard format for JavaScript's Date.prototype.toString() as well, according to MDN. The fact that I'm seeing in multiple places in unrelated contexts (JS/IMAP) makes me think it must be some sort of standard. Still can't find a name for it.
Unlike most SO answers, this is an admission of failure. Originally I thought this was the C library function asctime() - C casting its very long shadow over UNIX and hence the Internet. But as the OP pointed out, that would generate something of the form Tue Apr 12 09:45:14 2016 and not Tue Apr 12 2016 09:45:14 GMT-0500 (CDT). I should have stopped looking at this point, but curiosity pushed me on.
After much trawling, I believe that the format is not a standard but a bastardization of asctime and RFCs 822 and its descendants.
asctime (and cousins, e.g. ctime, strftime) gets you Tue Apr 12 09:45:14 2016, so the year is in the 'wrong' place and there is no offset or zone. I suspect this latter bit is environmental, affected by LC_TIME. The source code for GNU date appears to agree.See GNU date in the coreutils pkg source
RFC 822's timestamp format would produce Tues, 06 Apr 16 09:45:14 CDT.
RFC 2822's effort would be Tues, 06 Apr 2016 09:45:14 -0500, fixing the Y2K issue and being clearer on the offset from universal time. RFC 5322 is the same. And (aargh) introducing a comma after the day of week. See RFC 822, etc.
RFC 1123, although apparently not an Official Standard, persisted long enough that Java has picked it up as a standard format. This gets you Tue, 06 Apr 2016 09:45:14 GMT using things like the RFC1123 formatter
At this point I realized the irony of wasting so much time learning about time, and the double irony of knowing before I even started that time in computer programming is one of the most notoriously mis-understood and inconsistent areas of all and I should know better than to get sucked in. Let that be a lesson to you all. Flee, my friends, flee!
I've got some serialized json containing timestamps like:
"TimeStamp": "/Date(1362898800000-0700)/",
Which, when parsed correctly, is supposed to be:
Sat Mar 09 2013 23:59:59 GMT-0700 (Mountain Standard Time)
But its being parsed as
Sat Mar 09 2013 17:00:00 GMT-0700 (Mountain Standard Time)
I've got a couple questions, the first of which may help answer the second:
A) What is this format called?
B) How can I get Ext.JSON.decode() to parse these strings properly, or what format should I change it to from .NET, to get Ext.js to handle it properly?
I've searched and only found http://evilcroco.name/2010/12/make-extjs-parse-net-date-format-in-json/ but it's a little out of date. I'm just looking for a point in the right direction, and will update with code as I go.
Bonus Question!
What are some best practices or standards for plotting data on a chart in a timezone where daylight savings time is observed? Should it be converted to UTC?
the date has been parsed correctly it the culture that is making the difference. you are parsing the date at the client side so its taking into account your current culture which is -7 from the GMT.
consider saving all your dates in UTC, it never too late, once the application grows these date time issue go out of hand.
since you are using .net you can consider using noda time
here is an excellent SO answer which might help you Daylight saving time and time zone best practices
I have released an app which,. within its functionality displays date and time strings.
I am aware of the differing formats across cultures - however in some cases I had hardcoded values- for example I had gone with a custom format that was the 12 hr clock and showed AM/PM
I am now changing to use the standard date time format strings where possible, and so, for my times,I am now using the shortTimePattern.
What has surprised me is that for the US this shows as say 3:15PM but in the UK its 16:15 i.e the default there is the 24 hr clock.
Similarly in the US the long date includes the day of the week, where as in the UK it does not.
I am thinking that these defaults must be right and are what is expected within that country but is this really the case? I had no idea that the UK default would be a 24 hr clock. And, for those users in the UK who have the app, will they be annoyed when the next update shows the time in this format?
Interested in any opinions around this.
thanks
UK Users will not care between 24hr and am/pm (we don't talk to each other saying "It's fourteen hundred o'clock :P).
Dates are also fine unless you're using format of 12/02/12 as in the UK that's considered 12th Feb whereas in the states it's December 2nd.
This is not the place to solicit "opinions" on whether the behaviour provided by the framework is correct.
Assume that the framework is correct, unless you know otherwise.
If you want to know what your users will think you should ask them. (I assume that your users are not typical users of StackOverflow.) If you don't already have beta users in your target markets to ask then make the change to use the "standard" behaviour. If there is a problem your users will tell you.
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 :)
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.
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.
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.