GetDateFormat is Gregorian based

by Michael S. Kaplan, published on 2005/08/18 21:15 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/08/18/453373.aspx

The GetDateFormat function either takes a SYSTEMTIME struct or if you pass a NULL for that parameter it uses the GetSystemTime function to retrieve the current date in the form of a SYSTEMTIME struct.

One weird thing about all of that? Well, SYSTEMTIME is Gregorian calendar based.

So even if you have some other calendar selected as the current calendar (or if you specify a locale that has some other calendar as its default), you have to pass the current date as a Gregorian thing in order to format it as something non-Gregorian.

Some people have trouble with this idea conceptually (so luckily this is hidden from all but the developer types, who usually can deal with it okay). But in the end the system has to pivot off of some calendar. It is hard to begrudge software for going with the calendar that is the default where the software comes from, originally.

Imagine if it were not true, and every developer who called GetSystemTime was required to understand every other calendar in the world, depending on user settings.

One thing that is important to remember is my bias -- remember that old post Calendars on Win32 -- just there for show.... that kind of explains how the calendars are just for display purposes. The same is true of the dates, which is why everything I have said in this post is basically true.

As an alternative, we could have made all date functions use some kind of system that is indepenent of all calendars and pivot off of that. But imagine doing all that work to make sdure it is harder for everyone to work with the software. I am personally kind of glad that such a decision was not made. :-)

Well, I guess Microsoft needs to be more PC and start using fractions of a revolution around the sun to store time and convert that to a date :) That way they can be safe until we discover aliens or start colonizing other planets.

Is there a reason for not being able to store the gregorian value for internal use, and let the user use whatever basis desired?

Sort of like storing time in ticks or Julian Day Numbers, and converting dates internally to those to do calculations. Astronomers have been doing that for decades.

Wouldn't basing it off FILETIME be the same as making it calendar-independant? I mean, FILETIME is defined using the Gregorian calendar ("a 64-bit value representing the number of 100-nanosecond intervals since January 1, 1601 (UTC)") but it could just as easily be described in terms of other calendars.

So if you don't like the Gregorian calendar (or you just want to be difficult), you could just convert the date "January 1, 1601 (UTC)" into your own calendar, define the FILETIME structure in terms of that, and just do a FileTimeToSystemTime at the very last moment before calling GetDateFormat!

Am I missing something?

In UNIX-land, dates/times are stored as integers, representing a number of seconds (or milliseconds? I forget) since the "epoch" -- which is defined as the moment in time AKA 1/1/1970 12AM UTC Gregorian time. So effectively this is "another calendar".

This kind of calendar has some obvious advantages for computer use, though.

So why not store all dates/times in this fashion, and convert from Gregorian and/or Julian and/or what-have-you to this? The particular moment-of-epoch is irrelevant... and it is trivial to map from any new epoch-based "Microsoft calendar" to the existing "UNIX calendar" by adding or subtracting a fixed number.

Maybe not 100% on the subject, but it is about calendars.

I have always wondered if why there is no way to format a date with any calendar I want (for a certain locale). GetDateFormat gives you the result for the current calendar, or it can take DATE_USE_ALT_CALENDAR to use "the alternate calendar, if one exists."

But my problem is: how do I use one of the alternate calendars for locales with more then to? I can enumerate them, but cannot use them.

For Japanese I have 3 calendars:
- Japanese Emperor Era
- Gregorian (English strings always)
- Gregorian (localized)
Korean also 3:
- Korean Tangun Era
- Gregorian (English strings always)
- Gregorian (localized)
And some Arabic locales have up to 6:
- Hijri (Arabic Lunar)
- Gregorian (English strings always)
- Gregorian Middle East French
- Gregorian Arabic
- Gregorian (localized)
- Gregorian transliterated French

Missing API? Any chance to see this changing? Long^H^H^HVista?

Dean -- you are correct, though I assume that lots of people will have trouble thinking of FILETIME values that way!

Maurits -- much of the very underneath work does just that -- but it is not as intuitive for most people as something based on a calendar they know....

Heh, there it is:
http://msdn.microsoft.com/library/en-us/sysinfo/base/rtltimetosecondssince1970.asp

"It may be altered or unavailable in subsequent versions" -- (as Kyle's mom) what what what?

Maurits: The FILETIME structure is like UNIX time, except it uses 1601 as it's epoch, rather than 1970: http://msdn.microsoft.com/library/en-us/sysinfo/base/filetime_str.asp As long as you don't think "FILETIME only applies to files," (which, technically, it doesn't have to) then you're OK. And that RtlTimeToSecondsSince1970 looks like one of those APIs that were documented as part of the anti-trust suit :)