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



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