Here's from the latest disposition by Ecma regarding the restrictive 1900 and 1904 dates:
"Regarding the request that we adopt 1904 date base and remove 1900 date base support entirely, we do not see this as a viable option given the corpus of existing binary documents requiring support for the 1900 date base."
Do you remember our 5 Questions?
According to the OOXML specification (ECMA 376),
1. What day of the week corresponds to 1st January 1900?
…
5. How many days were in the month of February 1900?
Here are the answers you should get:1. The specification returns 1, meaning Sunday. In reality, the 1st January 1900 is a Monday.
…
5. Since 1900 is not a leap year, in the reality 28 days. Since the specification treats 1900 as a leap year, the specification gives 29 days for the month of february 1900.
The argument for a bug for bug compatibility shows the deficits of the migration to Open XML. I find it unacceptable that an international standard adopts bug-for-bug compatibility with historical versions of Microsoft Word. Ironically it was advertised as a feature of the format: backwards compatibility. It is well understood that backwards-compatibility is crucial but here the situation is different. Still the old binary formats such as doc, ppt, xls dominate the Office sphere. We are facing the slow transition to a new generation of formats for Office documents that are xml based. The existing ISO standard 26300:2006 was designed from the ground up while the candidate Office Open XML is a transition of the old formats into XML. You may call it a dump, they call it high fidelity. The result is that a central benefit of the transition is lost, i.e. to get rid off the design problems and cruft of the old Microsoft Office architecture manifested in its file format. Ecma wrote before in its response:
First, while both formats share the high-level goal, to represent documents, presentations, and spreadsheets in XML, their low-level goals differ fundamentally. OpenXML is designed to represent the existing corpus of documents faithfully, even if that means preserving idiosyncrasies that one might not choose given the luxury of starting from a clean slate.
In my opinion the so called backwards compatibility on the format level is a misconception. Backwards compatibility is to be achieved by a proper conversion of the conventions whereas the new format should resolve the bug.
Another aspect is that any change of the XML format would result into changes of the Microsoft Office products that is programming that is hard work that is costs. While the company puts a high burden on competitors to get its second standard supported it refuses to resolve its own cruft. Therefore the standard discriminates and is a barrier to trade. It may be very difficult to implement real changes in products of that maturity, also from an organizational perspective. But that is really no concern that does matter for global relevance of an ISO standard. Once again I refer to the Technical Barriers to Trade Agreement.
Which reminds me of all the fuzz about the year 2000 problem ("Y2K")? It was an exaggerated IT crisis over a bug in standardization and the industry spent billions to resolve it.
A man who makes a mistake and doesn't correct it, is making another."
Konfutse
