[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Date and Timezone: draft text
> > For reference, here is how OOXML defines it: ... > Given that a date-time has at least 25 different representations (and > likely many more), the statement "Functions that care only about the > time shall ignore any date information that is provided" means that > those functions would not well defined. > > How is this ever supposed to make sense? It doesn't, and it can't. This is actually the problem I'm trying to _avoid_. It's clear that, as part of the ISO process, somebody said "OOXML should support timezones", so somebody added some text about timezones. But that material is clearly incompatible with actual spreadsheets, and it's incompatible with other parts of the same spec :-(. Saying "timezones would be nice to have" must NOT translate into some random text that is unimplementable or is incompatible with existing spreadsheets. I'm sure that what they meant was "if you only need time-of-day, use X-INT(X); if you only need the day, use INT(X)." Please understand, I'm not against timezones. But since timezones have never been supported by spreadsheets, extreme caution is warranted. Unless there's an "obviously correct" solution for supporting timezones, that can also support existing spreadsheets, it's better to leave them out in this version. BTW, _not_ all timezones only increment the "hour" value; some have different values of "minutes". Kabul, Afghanistan, is UTC/GMT +4:30 hours. Katmandu, Nepal, is UTC/GMT +5:45 hours. And that's only an instantaneous timezone; daylight savings time creates MANY more complications. You CANNOT simply store everything as UTC and then do simple timezone corrections, while having existing spreadsheets actually work correctly. To store everything as UTC (as Unix and Linux systems do) requires sophisticated corrections for daylight savings time (which vary depending on geographical locations and the whims of legislatures). A Unix/Linux system can do this, and in fact it's a remarkably elegant solution for their time systems. However, this works because these systems _DO_ have information on which timezone is selected. This information that is not available in a numbers-only encoding (which is what a spreadsheet has). What's more existing spreadsheets do NOT expect to deal with this. There may be an elegant way to deal with timezones. But such an elegant way must be defined in great detail, support existing documents, and be "obviously right". Otherwise, let's not bother. There's no point in specifying a complicated system that gets it wrong. BTW, I used to lead work on doing time-related standards. --- David A. Wheeler
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]