Re: date:date-time()

On Sat, Jan 07, 2006 at 01:08:56PM -0700, Jeremy Kloth wrote:
> On Thursday 05 January 2006 12:30, Jeremy Kloth wrote:
> > The current spec for date-time() allows for either UTC (Z) or local
> > (-/+HH:MM) timezones.  If an implementation decides to use UTC there is no
> > way to determine what the local offset would be.  This also chains to the
> > rest of the functions as they then operate only on the UTC date/time.
> >
> > There should be some way of working with both the UTC and offset-based
> > timezones.  Some ideas:
> >
> > - mandate that date:date-time() allows uses the offset notation;
> >
> > - have date:date-time() grow an optional boolean argument that specifies
> > with to return the timezone in UTC or offset notation;
> >
> > - add an additional function, say date:convert-timezone(), that switches
> > from offset to UTC notation;
> >
> > - add an addition function, date:utc-offset(), that returns a duration that
> > represents the offset of the given date/time or current time.
> >
> > As it stands, the lack of control, by the user, over which format can cause
> > confusion.  For example, there was a comment on #4suite whether
> > day-in-year() was working because it was returning 1 day later than it
> > would have been if it was in local time.
> >
> > This issue needs to be resolved in some fashion, i'm leaning towards the
> > optional argument to date:date-time(), that when present and true, UTC
> > notation is used, otherwise offset notation.  I choose offset notation as
> > that is what is implemented by the Javascript versions and by the majority
> > of the processors (all except 4Suite which defaults to 'Z').

Jeremy and I had a lot of this conversation in #4Suite earlier today,
and I wanted to flesh out some of my points.  I have a relatively small
amount of experience with dates and times in EXSLT, in Python, and in
Java.  The starting point for this conversation was my plunge into dates
in EXSLT, where I was trying to obtain the current day in the year with
the `date:day-in-year()` method.  The value returned was one day more
than the day I thought it was.  I thought I was doing something wrong at
the time.

> Just responding to myself to add some followup research.  The "status
> quo" wrt the default timezone is the offset (-/+HH:MM) notation.  The
> reference implementations as well as libxslt, saxon and xalan all
> return with that for those functions that have a "default" value of
> the current time.  4Suite is the odd-man-out in this one.

I know that my default expectation in the case I mentioned above was to
obtain *my* day of the year, not from the perspective of UTC.  It took
me several minutes to figure out why the day was "in the future", from
my perspective.  Do others also have this expectation?

I agree with Jeremy's suggestion that we make this "local time" default
explicit in the EXSLT spec.  At the *very* least, we need to make the
EXSLT date and time section explicit as to what is going on, because I
couldn't find a lot of discussion on timezone support there.  As further
support, Java also defaults to the time zone from the current locale[0];
both since I find Java to be a good model for these kinds of details,
and because we already use Java as such a model elsewhere[1], I think
this is a good path to take.

> Some questions for the users of EXSLT Dates and Times out there:

Based upon my comments above:

> - is the return value of "local time" what you are expecting?

Yes, I think it is.

> - is "current time" just not used and therefore the TZ not an issue?
> In other words, only preexisting date/time strings are used.

I was using the "current time" in my code when I stumbled across the
issue above.

> - are dates/times in UTC not really important (or simply unused)?

I think we should be able to obtain formatted date and time strings
targetted for *any* time zone.  Further, I think UTC is a particularly
important time zone to support.

> OK, so now I'm going with the notion that date:date-time() ALWAYS returns 
> "local time".  Also an additional function, date:convert-timezone() is added 
> to handle the need for UTC (and other) timezones.  In template syntax:
> 
> <xsl:call-template name="date:convert-timezone">
>    <xsl:with-param name="date-time" select="string" />
>    <xsl:with-param name="timezone" select="string" />
> </xsl:call-template>
> 
> where date-time is either xs:dateTime or xs:time and timezone is either 'Z' or 
> '+/-HH:MM'.

I like this, but I also think that functions such as date:date-time()
should take an optional argument of a timezone designator such as 'UTC',
'-00:00', 'EST', or '-05:00' and return a string encoded for that
timezone, which is close to what you suggested in your original email.
That way the default can give the time encoded for the local time, but
other timezones can be explicitly selected.

Take care,

    John L. Clark

[0] http://java.sun.com/j2se/1.5.0/docs/api/java/util/Calendar.html#getInstance()

[1] http://www.exslt.org/date/functions/format-date/index.html

_______________________________________________
exslt mailing list
[email protected]
http://www.exslt.org/list

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)

iD8DBQFDwDi2jkcskvOyl78RArMoAKCjyPCRTT3nFzA0EpGvVZ50xCUSXwCfaYij
yoMOqyr01yWSuz0HqF2QqXM=
=O/RE
-----END PGP SIGNATURE-----