OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] Date and Timezone: draft text

> > 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    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"

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]