Implementer question about function adjust-dateTime-to-timezone()

This is a multipart message in MIME format.
--=_alternative 0070967E882578A0_=
Content-Type: text/plain; charset="US-ASCII"

It doesn't jump out at you in the spec, so I am wondering if implementers 
account for daylight savings time *at the dateTime given as input* rather 
than at the current local-dateTime() for the client processor?

For server-side implementations of XForms, work is already done to 
communicate the client-side timezone and daylight savings time information 
for each separate form, which may be coming from users in different 
timezones.

In the spec we give the following example:
adjust-dateTime-to-timezone('2007-10-02T21:26:43Z')

and we indicate the return value should be :
2007-10-02T14:26:43-07:00 in the Pacific time zone since daylight savings 
time applies. 

>From this it is clear that the function must account for daylight savings 
time.  Of course, it should account for the local timezone, but also for 
whether daylight savings time will be in effect at the time of the result, 
not at the time the function is called.

The third example of the function showed how to compute "two hours from 
now" in order to show one reason why we wanted the function.  A fourth 
example would have been better, to compute a 61 day advancement from 
2007-10-02T21:26:43Z in order illustrate the timezone shift.

In the Pacific Timezone, the following expression:
adjust-dateTime-to-timezone(seconds-to-dateTime(seconds-from-dateTime('2007-10-02T14:26:43-07:00
') + 61*86400))

should return a date that advanced two months (to Dec. 2), and it should 
be the same absolute time except daylight savings time will shift the 
clock, resulting in
2007-12-02T13:26:43-08:00 in the Pacific time zone since daylight savings 
time applies to the result.

Adjusting for your own timezone (other than 0) and assuming you have 
daylight savings time, could other xforms processors implementers comment 
on whether their version of ajust-dateTime-to-timezone() works as 
described above?

I'm just concerned that implementers may read "... to the local time zone 
of the implementation" to mean the timezone setting "now" rather than 
using the implementation's timezone setting now to compute the proper 
timezone setting for the input date.  If other implementations don't 
produce results that account for daylight savings time shifts, then 
perhaps we should produce an erratum,

Thanks,
John M. Boyer, Ph.D.
Distinguished Engineer, IBM Forms and Smarter Web Applications
IBM Canada Software Lab, Victoria
E-Mail: [email protected] 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw


--=_alternative 0070967E882578A0_=
Content-Type: text/html; charset="US-ASCII"

<font size=2 face="sans-serif">It doesn't jump out at you in the spec,
so I am wondering if implementers account for daylight savings time *at
the dateTime given as input* rather than at the current local-dateTime()
for the client processor?</font>
<br>
<br><font size=2 face="sans-serif">For server-side implementations of XForms,
work is already done to communicate the client-side timezone and daylight
savings time information for each separate form, which may be coming from
users in different timezones.</font>
<br>
<br><font size=2 face="sans-serif">In the spec we give the following example:</font>
<br><tt><font size=3>adjust-dateTime-to-timezone('2007-10-02T21:26:43Z')</font></tt>
<br>
<br><font size=2 face="sans-serif">and we indicate the return value should
be :</font>
<br><tt><font size=3>2007-10-02T14:26:43-07:00</font></tt><font size=3>
in the Pacific time zone since daylight savings time applies. </font>
<br>
<br><font size=2 face="sans-serif">From this it is clear that the function
must account for daylight savings time. &nbsp;Of course, it should account
for the local timezone, but also for whether daylight savings time will
be in effect at the time of the result, not at the time the function is
called.</font>
<br>
<br><font size=2 face="sans-serif">The third example of the function showed
how to compute &quot;two hours from now&quot; in order to show one reason
why we wanted the function. &nbsp;A fourth example would have been better,
to compute a 61 day advancement from </font><tt><font size=3>2007-10-02T21:26:43Z</font></tt><font size=2 face="sans-serif">
in order illustrate the timezone shift.</font>
<br>
<br><font size=2 face="sans-serif">In the Pacific Timezone, the following
expression:</font>
<br><tt><font size=3>adjust-dateTime-to-timezone(seconds-to-dateTime(seconds-from-dateTime('2007-10-02T14:26:43-07:00')
+ 61*86400))</font></tt>
<br>
<br><font size=2 face="sans-serif">should return a date that advanced two
months (to Dec. 2), and it should be the same absolute time except daylight
savings time will shift the clock, resulting in</font>
<br><tt><font size=3>2007-12-02T13:26:43-08:00</font></tt><font size=3>
in the Pacific time zone since daylight savings time applies to the result.</font>
<br>
<br><font size=2 face="sans-serif">Adjusting for your own timezone (other
than 0) and assuming you have daylight savings time, could other xforms
processors implementers comment on whether their version of ajust-dateTime-to-timezone()
works as described above?</font>
<br>
<br><font size=2 face="sans-serif">I'm just concerned that implementers
may read &quot;... to the local time zone of the implementation&quot; to
mean the timezone setting &quot;now&quot; rather than using the implementation's
timezone setting now to compute the proper timezone setting for the input
date. &nbsp;If other implementations don't produce results that account
for daylight savings time shifts, then perhaps we should produce an erratum,</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br><font size=2 face="sans-serif">John M. Boyer, Ph.D.<br>
Distinguished Engineer, IBM Forms and Smarter Web Applications<br>
IBM Canada Software Lab, Victoria<br>
E-Mail: [email protected] &nbsp;<br>
<br>
Blog: </font><a href=http://www.ibm.com/developerworks/blogs/page/JohnBoyer><font size=2 face="sans-serif">http://www.ibm.com/developerworks/blogs/page/JohnBoyer</font></a><font size=2 face="sans-serif"><br>
Blog RSS feed: </font><a href="http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw"><font size=2 face="sans-serif">http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw</font></a><font size=2 face="sans-serif"><br>
<br>
</font>
--=_alternative 0070967E882578A0_=--