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

2008/7/7  <robert_weir@us.ibm.com>:

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

No, they are ambiguous as to TZ.
Anything beyond that is a presumption.

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

That's one interpretation.

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

Fine if Boston users never communicate with London users.
They do.

That' the interop problem.


provides a reasonably comprehensive set of thought out datetime functions.


Dave Pawson

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