It will die over time as people move to typed spreadsheet formats. At some point, probably in five years or something, the feature will get dropped from the specs., then later the apps will stop supporting it.

There’s not really a huge amount of point removing stuff from the specification while it’s still in use by users and has to be supported by applications. That’s one reason why HTML5 is a lot more promising than XHTML2: in fact, XHTML2 is almost the case study in why technical perfection does not work.

So if _that_ is already given – what is the plan to get rid of the hack in the long run? I mean, even if I accept that this hack can’t be fixed _now_, can I at least expect that people are working to completely fix this over the coming years? Or did you actually mean to say “This hack will be with us for as long as Microsoft is in business”?

The y2k issue was neither quick, nor cheap; it was what you’d call “paying for past sins”. The same needs to happen with these date and calculation bugs. Just define a bug a standard is as ridiculous as redefining the meaning of noon during “summer time” (there’s no such time, because noon is when the sun is highest, not when a bunch of politicians decide it to be).

The reason I bring up summer time is no accidental: instead of having summer and winter HOURS (as in opening or business hours), the government decides to “cheat” everyone by redefining an astronomical event. They could equally easily mandate that school and government office hours start one hour earlier in summer, and more or less the rest of the economy would follow suit (working parents have to bring kids to school, business want to sell to government, etc.)

That would be the right approach.
It seems that getting things done right doesn’t count anymore, only slop counts, as long as it “gets done, who gives a f* how it gets done”. And it’s that attitude that creates that sort of mess in the first place.

If you screw up, you have to pay for it. You can pay now, or a lot more later. The price just goes up the longer you wait.

So the point of a quick transition is completely lost if the transition doesn’t fix the legacy issues in the process. I rather see a much slower transition and adoption, but can count that there are no dead legacy dogs buried in new documents.

>> @rcfa: with that attitude, we’d be stuck with .xls forever more.

Wouldn’t that be .wks instead?

I think you actually raise two different problems. The “leap year” bug is a very specific and quite unique issue, in that it’s basically impossible for software to “fix” spreadsheets. The best approach so far is to put the standard (legacy) epoch back one day into 1899, so that the values are 99% correct without the need for any conversion; only people with spreadsheets that care about days in 1900 will experience problems. That’s sound engineering.

The other issues, like YEARFRAC, are where OOXML is not soundly specified enough. I think this is just competition in action: one early advantage of OOXML was that it went much deeper than the OpenDocument specification, and this was touted as a benefit. Now, the boot is somewhat on the other foot, because OpenDocument is reaching the same depths but at a greater level of detail.

We’re sadly still in the same situation of copying what Excel does, but that’s because this is really user interface. Any change here impacts users, not the vendors.

I’m on the same page as Jose as far as choice is concerned for using X or Y alg or reference point, however as Rob Weir showed in his piece regarding the YEARFRAC function (http://www.robweir.com/blog/2008/05/fractured-yearfrac-and-discounted-disc.html), those algoritms and reference points need to be unambiguously defined lest we run the risk of crashing another bank or Mars lander ^^

And if we have two well defined algoritms with associated reference points, it’s a trivial excercise to specify a mathematical mapping from the faulty one to the correct one AS LONG AS one point in the faulty specs space doesn’t map on multiple points of the correct space. If the latter case occurs, context will need to be taken into account to try and estimate the correct mapping and as with all algoritms taking context into account, the best judge of the final result will probably be a human.

The bigger question though is: how many documents CANNOT be mapped automatically, i.e. need context and maybe human intervention to correct any errors?

However, SC 34 is still muddying the waters regarding the future spec unifying ISO 29500 and 26300, diluting that process with the simultaneaous task of ensuring the mapping of legacy MS documents to the new format will be relatively painless for MS (i.e. NOT aiming for the best possible unified format for the next coupla decades). Already a number of countries encompassing a sizable portion of the globe’s population have stated their prefered document format is ODF, so if SC 34 doesn’t cut away all legacy fluff from ISO 29500 and strive for unification by the end of 2009, their efforts will become wholly irrelevant. And that would definitely be a shame, as that committee is about the only forum outside MS that is at all able to draw up mappings from faulty specs to correct specs…

First things first:
1) A (mathematically correct) unified document format by the end of 2009
2) see 1
3) see 1
4) As soon as 1 has been developed, spawn X workgroups to help out with conversion algoritms from legacy to unified.

ISO was, in part, stuffed by Microsoft employees, so the decision to let this abomination happen was down to Microsoft, too. This impulsive thing was a response to corruption in the process where people got bullied, bribed, blackmailed. I thought that only the ‘non-finalisation’ of the text was the reason it was not out there. It’s surprising to find that so-called ‘open’ standards are not open even for access (an afterthought and a realisation that came to me only later, so I removed the files).

@RJoe: one of the things ISO has always done is charge money for paper standards. They’ve never been published openly except where another organisation also has their own copy (e.g., OpenDocument). That’s obviously something which ought to change.

Your point about dates is correct, and you’ve actually pointed out how the modern date type basically works. But as I said previously, it’s not as simple as saying “just convert old data”, because you can’t. This hack will be with us for many years to come.

First: How can the documentation of an ISO-standard be secret? is there no obligation to publish such a document???

Second: A new standard should not implement errors of previous applications. The 1900 bug should not even have any effect on the OOXML formatted data, because we talk about a calendar date. This should be formatted yyyy.mm.dd or something like that, but not in days starting from a specific date! If an application wants to be compatible with previous versions, it can rebuild it in it’s internal data.

It’s a shame what happened in norway these days. The oficials from ISO don’t have any spine. Otherwize they have rejected this document from MS.

stealthnet://?hash=6AED03BB4BA2B91393BB5E97E5CCA8F49BBF650BD33D7D59D446B4EAA4B10FE2A78528CAA3F48E00EDD075E6A014FD5AC924FDEEB7B4B3CF63ED88860437CE48&name=OOXML-ISO-standard-english_leaked-html-edition_october-2008-1080-boycottnovell.com.rar&size=164435005

use stealthnet for your p2p needs and participate to make it larger and stronger and enrich it with your content.

dont let these war- and money mongers rule this planet and enslave humanity any further.

@Roy: that is a quote dating back about eight years now, though.

Ah! That makes it OK. Let’s just forget all the crime where (age >= 2 years).

The Web Standards Project has had a Microsoft Task Force for a number of years now, which seems to be having a real effect.

The web browser market has been changed massively by free software, and Microsoft are not in a position to ignore standards now. And if you want to see fewer places use Silverlight, you should be rooting for better standards support in IE, because without SVG/etc. you don’t have many other options – and it’s only IE behind in that area.

“We’re disheartened because Microsoft helped W3C develop the very standards that they’ve failed to implement in their browser. We’re also dismayed to see Microsoft continue adding proprietary extensions to these standards when support for the essentials remains unfinished.”

–George Olsen, Web Standards Project

Having a transition plan is the only way you can get people to upgrade to new formats like OpenDocument.

It’s not technically nice, no. But it’s a practical necessity. A new format which people can’t upgrade to is of very little use to people who need to do real work.

Reminds me of piracy.

It’s all good for the vendor.

Nach vielen auftauchenden Unregelmäßigkeiten bei der “Normierung” von OOXML ist nun auch der Standard an sich im Netz aufgetaucht. Typisch ist, dass die Copyright-Keule ausgepackt wird und im Blogeintrag deshalb die Datei nicht mehr zu finden ist:
…