Re: date:date-time()

John L. Clark wrote:

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

agree with the points raised in this thread, getting date time right in
any computing context is difficult.

if any changes are to be made though I would imagine it would have to be
bundled in a point release of EXSLT.

any thinking or discussion should be contrasted with the approach taken
with XPATH Functions 2.0 doc

http://www.w3.org/TR/2005/CR-xpath-functions-20051103/#durations-dates-times

not suggesting to replicate XPATH functions; though considering how much
space is devoted to date time functions in the spec I find it a
useful doc to refer to when discussing or trying to completely define
date/time functionality.

cheers, jim