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.

The ODF specification uses the ISOform Gregorian date forms, described earlier, as the way date values are conveyed in interchange, and again they may be presented differently. In ODF 1.0 there is no discussion of serial (i.e., Julian-style offsets) dates in the ODF handling of date-time.

I have not checked how OpenFormula addresses the need to perform calculations with values of date-time types. ODF 1.0 does provide a separate datatype for intervals of time, and I presume that scheme applies when the values of time intervals are conveyed as such. I don’t know how and whether those are amenable to manipulation as arithmetic values in OpenFormula and in existing ODF-supporting spreadsheet applications.

And I sincerely hope the Oasis format doesn’t ‘just store as dates’ either. It ignores the internationalisation issue that not everyone uses the Gregorian Calendar, e.g. the Islamic and Jewish calendars.

There’s a standard, well known, and widely implemented way of recording dates and calendars in a completely neutral way, that is the Julian Day system as widely seen in astronomy. This separates days and calendars, numbers each day relative to a universal epoch day, and has formulas to convert day numbers to and from various calendar systems.

You need to store the date itself solely as a day counter making for easy maths, and then store the required display calendar system separately and only apply the conversion formulas where needed.

John.

The problem also happens on import, of course, and we can’t always know which imported formulas depend on the external sequence number mapping and must be restated somehow.

In this respect, I think there’s already a problem having both 1900 and 1904 supported. I wonder how often those worlds collide during Spreadsheet interchange.

In a spreadsheet that I use every day, I know to write formulas like

=B15+(DATEVALUE(“2006-05-07″)-DATEVALUE(“2006-05-06″))

for cell B14 (with most-recent date at the top of the form) and

=CHOOSE(WEEKDAY(B14),”Sun”,”Mon”,”Tue”,”Wed”,”Thu”,”Fri”,”Sat”)

for cell A14, so this should travel back and forth in OOX no matter what the game is. Maybe most date manipulations are easy to adjust without tricks to avoid knowing the representation like those I use. I do assume one can do arithmetic on date representations though.

[By the way, when I import my .xls into Open Office Calc and save it as .ods, the OpenDocument Spreadsheet format, those formulas are carried over exactly into the OO.o implementation of ODF Table Cells and formulas, and the same dates are presented, in the same format, in the visible presentation of cell values. Something tells me that spreadsheet developers are already dealing with Excel's off-by-1 serial-number problem.]

This reminds me of another problem commented on in my What We See Is Not What We Get.