- From: John Boyer <boyerj@ca.ibm.com>
- Date: Mon, 30 May 2011 13:29:38 -0700
- To: www-forms@w3.org
- Cc: public-forms@w3.org
- Message-ID: <OF9D812CCF.C26C4BAA-ON882578A0.0066CA4A-882578A0.0070974B@ca.ibm.com>
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
Received on Monday, 30 May 2011 20:31:45 UTC