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

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: boyerj@ca.ibm.com 

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