The ODF date format can be directly used in standard XSLT date functions, the weird OOXML format cannot. So even though the need for a “semi-presentational” format in ODF is arguable, this particular format is much easier to convert to a real presentational format using standard XSLT.

They could have specified a MS-Gregorian Calendar with the 1900 glitch and a MS-Mac-Gregorian Calendar with the 1904 epoch.

And use internally the UTC epoch (which I _think_ should be correct).

“It’s a bug in Excel!” I exclaimed.

“Well, not really,” said Ed. “We had to do it that way because we need to be able to import Lotus 123 worksheets.”

“So, it’s a bug in Lotus 123?”

“Yeah, but probably an intentional one. Lotus had to fit in 640K. That’s not a lot of memory. If you ignore 1900, you can figure out if a given year is a leap year just by looking to see if the rightmost two bits are zero. That’s really fast and easy. The Lotus guys probably figured it didn’t matter to be wrong for those two months way in the past. It looks like the Basic guys wanted to be anal about those two months, so they moved the epoch one day back.”

“Aargh!” I said, and went off to study why there was a checkbox in the options dialog called 1904 Date System.

Cheers!
Daniel

Q: How many Microsoft employees does it take to change a light bulb?

A: None. Darkness is the new industry standard.

=IF(TODAY()=39013, “Due Today!”, “Not Due Today!”)

I’d note that this is a problematic formula, even in legacy Excel files. In particular, it will give different results on Excel on the Mac versus Excel in Windows. So anyone who wrote formulas like that has already foregone any hope of portability.

Also, I see no good explanation for why the WEEKDAY() function is explicitly defined in the Ecma specification to give incorrect answers. Microsoft has obviously already conditionalized the function to work correctly on both the Mac and Windows. Making it work correctly according to the Gregorian Calendar would have been trivial. It amounts to an “If” statement.

Microsoft can yell “40 billion documents!” all they want, but Monday remains Monday and Tuesday remains Tuesday. I’m generally an open-minded guy, but I don’t think any amount of rationalization will change that fact that the Gregorian Calendar has rather more weight in the world of standards than Microsoft’s errors, no matter how stubbornly they cling to them.

They can’t use MathML — not good enough. Can’t use SVG — VML is needed for legacy reasons. XForms? Not even considered, they have their own InfoPath stuff. PDF? Nah. We have XPS. JPG? Nope. We’ll push Windows Media Photo Format. Gregorian Calendar? Sorry, Pope Gregory XIII’s scheme wasn’t good enough. They follow Pope Bill III.

It just shows that there is no standard so stable, so well established, so universally adopted that Microsoft will not push it aside and attempt to replace it with their own.

Now, I am not sure which is more painful in the target interchange use of OOX: using a correct scheme or acknowledging and perpetuating the Excel defect. It would be interesting to see how the people working on converters between OOX and ODF manage to deal with this.

Meanwhile, for this particular case, I see a potential compromise.

In the OOX specification, consider defining the default serial date representation such that

2. Being defined only for representation of dates from March 1, 1900 (lower-limit serial value 61) through December 31, 9999 (upper-limit serial value 2,958,465).

That should allow interchange of existing formulas and also leave Microsoft Office Excel to deal with export of out-of-range serial numbers and with the problematic conversion of date February 29, 1900.

In this particular case, it seems that declaring a documentation bug that is corrected without invalidating actual usage in a tremendous number of existing spreadsheets is the way to go. I’ll try this one out on TC45.

Meanwhile, I don’t know what to say about the 1904 case. I think there is no easy way to be sure that formulas aren’t broken when going into a non-1904 application, even though the defined 1904-style range is trivially mappable into the revised 1900 range I propose above. Maybe the people at Apple and those working on converters will know better whether such cases are likely to occur in the wild.