office message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [office] Date and Timezone: draft text
- From: robert_weir@us.ibm.com
- To: office@lists.oasis-open.org
- Date: Sun, 6 Jul 2008 21:54:33 -0400
>
> > David, I wonder if we want to explicitly state that the OpenFormula
dates
> > are explictly in UTC instead of "unspecified time zone"?
This would give
> > us something definite to work with if we decided to add timezone
> > sensitivity in a future version.
>
> I think that's WORSE. Almost no spreadsheet documents actually
> use UTC, so it would be a lie. It'd also make it hard to add
real
> timezone support later.
>
>
Thinking out loud here.
My main concern is that functions like HOUR()and MINUTE()
which extract the hour or minute value from a datetime value are unambiguous.
If we throw in time zones, then I think we lose that. (What
is HOUR(15:27:46+01:00) in Bangalore, India?)
ISO 8601 states that the notation "18:30:00"
expresses local time. You can make it expressly UTC by writing "18:30:00Z".
Similarly, you can give a specific time zone offset by writing "18:30:00+05".
Each of this notations can be combined with dates to give strings
like "2008-12-24T18:30:00+05".
So if we merely leave it as-is, then the date/time
values are stored in local time, in an application-dependent fashion, in
what may be a time-zone dependent fashion as well. That is how the
spec reads to me now.
But I don't think implementations work that way. If
I enter the NOW() function into a spreadsheet in Boston, and at the same
instant someone enters NOW() into a spreadsheet in London, we do not see
the equivalent times recorded. We each record our local times, without
specifying a time zone.
That is how it is done today, by all spreadsheets
that I'm aware off.
So let's look at your proposed text:
>The Date and Datetime subtypes (number of days since the
>beginning of the epoch) do not include a mechanism for recording the
>time zone. Instead, these subtypes only presume that all
>date or datetime values use the same unspecified time zone.
>Document creators CAN use formulas to do time zone
>translations using formulas, and CAN decide on a particular single
time zone
>such as UTC (Coordinated Universal Time) when developing a particular
document.
>Similarly, the Date and Datetime subtypes do not include a mechanism
>for distinguishing the value of a leap second and the following second,
>and presume that every day is exactly 24 hours long.
In first sentence, can we simply say something like
"Date values shall be stored using the Extended 'Complete Calendar
date' notation defined in ISO 8601:2004, clause 4.1.2.2. Datetime
values shall be stored using the Complete 'Date and time of day' notation
defined in ISO 8601:2004, clause 4.3.2, with empty zone designator in accordance
with local time provisions of ISO 8601:2004, clause 4.2.2.2."
I think that restates your main thought, in ISO 8601
terms.
As for leap seconds, ISO 8601 notates them as "23:59:60"
followed by "00:00:00". So we could handle them if we wanted,
by modifying SECONDS() to return a value from 0 - to 60, instead of 0-59.
But I doubt any spreadsheet treats these two values as different.
-Rob
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]