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: Mon, 7 Jul 2008 08:36:24 -0400
"Dave Pawson" <dave.pawson@gmail.com>
wrote on 07/07/2008 02:49:20 AM:
> 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.
>
You are wrong. These functions are not ambiguous.
They give the same answer on every spreadsheet, in a location/time
zone independent fashion. This is not presumption. This is
accurate observation. This is what the users see today, what they
are accustomed to, what they expect.
>
> >
> > 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.
>
Care to offer another interpretation? ISO 8601
seems clear on this point.
>
> >
> > 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.
>
If we did what you suggest, every user of an ODF spreadsheet
would get answers that contradict what Excel and every other spreadsheet
does, and would generally cause chaos as financial spreadsheets gave different
answers as they were mailed around the world.
Is this interoperability?
> http://www.w3.org/TR/xpath-functions/#func-current-dateTime
>
> provides a reasonably comprehensive set of thought out datetime functions.
>
And there is a place for this. But current practice,
and current user expectations is that date calculations are not time zone
sensitive in spreadsheets.
-Rob
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]