Microsoft ametlikult 425 aastat ajast maas
Minut refereerib:
“Veebruar 29. pole õige kuupäev, arvab Microsoft: Microsoft officially 425 years behind the times. Mitte ainult Excel ja Exchange ei ignoreeri Gregooriuse kalendrit. Sama lugu on ka tuttuue andmebaasiserveriga SQL Server 2008 ning ka Windows Small Business Server ja Windows Mobile ei pea seda kuupäeva miskikski. Windows Mobile 2003 olla vahetanud oma kuupäeva 1. märtsiks 2035, SQL server keeldus käivitumast, jne”
Märkuseks siinkohal, et ka Microsofti pakutud uus kontoritarkvara failivorming OOXML sisaldab eelpoolmainitud viga liigaasta käsitlemisel.
The date issue highlights several other problems. The original text proposes to store and manipulate dates by using two different representations, i.e. number of days from either 1900 or 1904, which contain a deliberate error for backwards compatibility: 1900 is considered to be a leap year. Other problems that were pointed out were that specifying dates before 1900 is not possible, that there is no reason to have two representations when one is enough, and that new ways of storing dates should not be invented since we already have ISO 8601. In the Disposition of Comments, Ecma proposed to add two additional ways of representation, which solved some of the problems but complicated the problem too much.
Before the BRM, I had prepared an alternative proposal on dates, which is much cleaner. There are three issues that demonstrate how the whole process was affected by the time constraints.
The first issue is that my proposal for dates, despite the fact that I had written it with care in the course of a few weeks, and that it had been reviewed by several people, did have shortcomings. By comparing my work to the work by Ecma and Germany I found out that I had failed to notice that data types were described in two places, 3.17.2.6 and 3.18.12, and I had only noticed 3.17.2.6. And while thinking about the whole issue I saw that the way I had proposed for handling durations probably did not work (although now I’m having second thoughts – but I’ll need very careful studying of ISO 8601 to arrive at a good conclusion). Both problems were easy to fix, and I submitted an updated proposal on Friday morning. However, this shows that it was very hard to write error-free proposals when the magnitude of changes were so large.
The second issue is related, but more important. When I discussed my proposal with Brian Jones on Thursday morning, he pointed out that it would be difficult for Ecma to accept it, because they did not have the time to verify that it actually works in all cases. Now this was a very valid concern. My proposal was more than 30 pages. Even if it were well thought and error free, Ecma had no way of knowing that. Therefore, the BRM was essentially confined to making changes that only scratched the surface of the problems.
The third issue is that, while writing my proposal, I and my reviewers found 13 additional errors in the original specification. However, national bodies were not allowed to submit new comments (and rightly so, otherwise there would have been total chaos). Therefore, there was no way to submit and correct them.
The changes that actually passed in Friday morning did add the possibility to store dates in ISO 8601 format, but they also keep the old ways, and in addition they add all ways proposed in the Disposition of Comments. Therefore we now have five different ways of representing the same thing.