GetDateFormat is Gregorian based

by Michael S. Kaplan, published on 2005/08/18 21:15 -04:00, original URI:

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.

Imagine how your code would only work with some user settings and not others!

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. :-)


This post brought to you by "۝" (U+06dd, ARABIC END OF AYAH)

# Shaun Bedingfield on 18 Aug 2005 10:20 PM:

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.

# Keith Farmer on 18 Aug 2005 11:41 PM:

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.

# Dean Harding on 18 Aug 2005 11:46 PM:

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!

# Maurits [MSFT] on 19 Aug 2005 11:52 AM:

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.

# Mihai on 19 Aug 2005 12:40 PM:

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?

# Michael S. Kaplan on 19 Aug 2005 1:11 PM:

Mihai -- see for more info.

For the Vista question, no comment at this time. :-)

# Michael S. Kaplan on 19 Aug 2005 1:17 PM:

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....

# Michael S. Kaplan on 19 Aug 2005 1:18 PM:

kfarmer -- see my prior response, which covers that thought. :-)

Shaun -- what if we wanted people using smartphones on the shuttle or on the trip to Mars? :-)

# Maurits [MSFT] on 19 Aug 2005 4:55 PM:

Heh, there it is:

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

# Michael S. Kaplan on 20 Aug 2005 4:41 PM:

Maurits -- yes, that one exists. Of course I try to avoid using functions that have built-in warnings about expiration dates.... :-)

# Dean Harding on 21 Aug 2005 7:53 PM:

Maurits: The FILETIME structure is like UNIX time, except it uses 1601 as it's epoch, rather than 1970: 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 :)

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

go to newer or older post, or back to index or month or day