Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI/W3C (chair)
Leigh Klotz, Xerox (minutes)
Alain Couthuries, AgenceXML
John Boyer, IBM
Nick van: I am testing it in
Orbeon, as it uses the same mechanism we use in our following
implementation. They use the xs:dateTime constructor from XPath, so
it gets a one hour offset, but I'm not sure what you're
asking.
John Boyer: Are you on daylight
savings time now?
Nick van: Yes.
John Boyer: The key then would be to
feed the function a date or dateTime near December.
Nick van: Yes, your example gets me a
one-hour offset.
John Boyer: What is the timezone value
in the datetime it returns?
Nick van: CET. I put in 12:00 and get
back 11:00 in the output.
John Boyer: What are the last 5
characters of the string it returns?
Nick van: It's getting CET, my
timezone, with an offset of 1 hour, so it's compensating for
DST.
Steven Pemberton: Does it return CET
at the end?
John Boyer: That's not a valid
datetime anymore; that's a presentation.
Nick van: That would be -1 I think. It
compensated the hours for daylight savings time.
John Boyer: It figured out something
from the users input of Noon December 12th and said that's 11:00
December 12th, which seems unusable as that's not what they meant.
Unfortunately our spec doesn't say exactly what to do. It doesn't
say how to adjust to the local timezone. There's offset and DST or
not. We don't say how we make that adjustment.
Nick van: Saxon also gives a one-hour
difference so that's likely what XPath does.
John Boyer: It may be that we need to
give feedback to them. It should be that the user should enter the
date and time. The adjustDateTimeToTimezone should add the timezone
for that locale at that time, not the current time and date of
now.
Steven Pemberton: I can see the
advantages of giving the timezone as it would be at that moment,
but it's difficult to do. Timezones are done by fiat, not
algorithmically. What do you think should happen? Should the
algorithm do a best guess?
John Boyer: I don't think there's a
problem. The algorithm is determining whether to make a DST
adjustment. It's adjusting the time component of the user's input,
not the timezone offset. What I think should happen is that the
user is given us a date and a time, and when they hit tab, I have
to provide an xsd:dateTime. In order to do that, I have to adjust
it to what their timezone is going to be at that datetime they've
entered. If someone says noon on that day, we don't want it changed
to 11:00 on that day because they exited daylight savings
time.
Nick van: The example I pasted in the
IRC
adjust-dateTime-to-timezone(xs:dateTime("2011-12-12T12:12:12"))
Mon Dec 12 11:12:12 CET 2011'
John Boyer: That's not valid
xsd:dateTime because there is no timezone +01:00.
Nick van: Is it mandatory?
John Boyer: If you specify it the
timezone format is mandatory. Does it output CET? That looks like a
presentation value.
John Boyer: I should still get -0700
out of this function because the input is within daylight savings
time. The timezone settings from the implementation should do
that.
Leigh Klotz: There are two
conversions: The conversion on the way in, and the one on the way
out. On the way in, the form author needs to know whether they user
is expressing a "local" time (i.e., noon), or they are expressing a
universal time, (i.e., the time that's noon right now but could
vary depending on what DST setting is.) Once the data is entered it
should be considered fixed as UTC.
Nick van: If there is no timezone
attached it assumes local time
Leigh Klotz: What about when DST
changes occur differently?
John Boyer: That's an exception.
Leigh Klotz: What do you convert to?
The 5-characters of the timezone at that date?
John Boyer: Yes.
John Boyer: It's the timezone of the
client.
Leigh Klotz: How do you get the local
timezone of the client?
John Boyer: We use information from
the browser. It's not trivial.
Leigh Klotz: I'm not aware of any Web
API calls for timezones.
Steven Pemberton: How do you calculate
that except for very recent events, whether DST is in effect?
Steven Pemberton: It's a property of
your legislative area. In Australia there are states don't go to
DST, and states that do.
Leigh Klotz: Or by county.
Steven Pemberton: How do you work it
out?
John Boyer: On the client machine the
user makes a decision.
Steven Pemberton: But not for future
dates.
John Boyer: In some future date we
don't know what the law might be.
Steven Pemberton: If I ask for Mar 27,
2013, is that daylight savings time?
Nick van: It changed for us a couple
of years ago and there are constant updates.
Nick van: The only way to be
interoperable is from the current timezone.
Leigh Klotz: I'm not sure the UI has
to be interoperable, just the functions.
Leigh Klotz: The question is what to
do with adjust-dateTime-to-timezone when there is no timezone in
the string.
Nick van: That's what John was
asking.
John Boyer: Yes. Even if the input
does have a timezone attached, what timezone should the output
have. If Nick gives me a dateTime that is 2011-12-12T12:00+0100
(non-DST for Nick), he'll send that date to me, and the software
has to show me that dateTime in my timeZone.
Leigh Klotz: What software?
adjust-dateTime-to-timezone?
John Boyer: Yes, I should get a date
and time in -0800. I expect this to show me the dateTime in my
timezone so I can make this meeting.
Leigh Klotz: I think this function is
overconstrained and it needs to know user intent and legislative
locale, which are UI operations.
John Boyer: It has to to use the
timezone info for the local implementation, which is what is offset
right now and when do I right now enter and exit daylight savings
time. Within the bounds of those limitations, this function should
return the same value for input within those limitations, so unless
the local implementation changes (out of band side effect info)
this function would always return the same value.
Nick van: This is from XPath 2.0:
[Definition: Implicit timezone. This is the timezone to be used
when a date, time, or dateTime value that does not have a timezone
is used in a comparison or arithmetic operation. The implicit
timezone is an http://www.w3.org/TR/xpath20/#dt-implementation-defined
value of type xs:dayTimeDuration. See http://www.w3.org/TR/xpath20/#dt-implementation-defined
for the range of legal values of a timezone.]
Nick van: So the implicit timezone is
implementation-defined. Saxon works out it is specified. We have to
be careful if we change it; we need to be more specific.
John Boyer: There is a problem even if
you do have a timezone in the input. If I need to figure it out on
that date.
Nick van: If you're planning a
meeting, you specify a time, but if you specify a location you now
the complete timezone information. If we plan a meeting in Boston
time during the week in which US and Europe are different for
daylight savings time,
John Boyer: -0500
Nick van: It's converted with
adjust-dateTime-to-timezone for me.
John Boyer: You're describing the
exact thing I want to work, even when there is a difference between
my DST and your DST. Boston is -0500 standard time and -0400 (I
think) DST. So if someone picks 11:00 AM it should get a -0400 DST
or -0500.
Nick van: You need to attach the -0400
or -0500 depending on the spec.
Leigh Klotz: If the UI control gives
you a dateTime without a timezone you've already lost.
John Boyer: If it gives you the
timezone, a -0500 gets attached to it, then I send that to Nick it
will tell you the meeting is at 12:00 your time, but at the time of
the meeting you won't be in DST.
Nick van: If you attach a -0500 that
doesn't change. The exact number changes when you choose -0500 or
-0600 that should never change. The only problem is creating the
date in the first place. You should point to an xs:dateTime and
there is no problem.
John Boyer: No, there is a problem. If
I pick 11:00AM Eastern Time on December 12, to get an xsd:dateTime
it has to attach -0500.
Nick van: The UI can know. If you pick
a date too far in the future you don't know. But if you know when
DST changes then you can pick the correct corresponding
timezone.
John Boyer: Software does that all the
time right now. If the law changes in the future people do software
updates and change data values and we deal with that when it
happens. In the meantime if I set a meeting for a particular time
and you receive that, that gives me a timezone with a
qualification.
Nick van: I am quite suer it works if
you specify the correct offset and it's the responsibility of the
UI, not the user, to specify the correct offset. The user isn't
going to say December 12, 12:00 -0100. The user will say CET. The
software has to change it to a specific offset.
Leigh Klotz: I agree; I don't see
where this function comes into play in this issue. The calendar
widget should do this.
John Boyer: So an XForms author cannot
use this function to build a calendar system?
Nick van: You can.
John Boyer: If we both choose December
12, 9:00 PM yours is 8:00AM my time. If we ignore the week
difference in DST change (irrelevant), when you pick a value it
applies +1 or +2 to your dateTime value. My
adjust-dateTime-to-timezone should apply either -8 or -8 to match
whatever mine shows.
Nick van: If in the instance a +/- is
saved depending on which day it is, then everything will work. If
you omit the timezone information and give that value, then
everything breaks.
Leigh Klotz: I believe if you use this
function without a timezone, it will almost certainly not do what
you want.
Nick van: As Leigh points out, store
the timezone information in your instance.
John Boyer: So Nick, if I attach -0800
to December 12 and you call adjust-dateTime-to-timezone it will
attach +1 because the date is not in DST for you.
Nick van: Yes.
John Boyer: Even if now you are in
DST?
Nick van: Yes, I think that is what it
does.
John Boyer: So this function totally
works correctly if the input has a timezone? You're saying it will
attach a different timezone based on whether that time is in
DST?
Nick van: If I am correct in
interpreting the result then that is what I expect.
John Boyer: Why would the behavior be
different if the timezone isn't specified?
Nick van: It attaches the current
value of the timezone to the dateTime, the implicit timezone.
John Boyer: It is implementation
defined and we can decide it. Why doesn't it do the same when there
is no timezone?
Nick van: I think in XPath you don't
get the date to retrieve the implicit timezone information. It uses
the timezone from the dynamic context.
John Boyer: So
adjust-dateTime-to-timezone(2011-12-12T11:00:00Z")
with a Zed. Youre saying the result in CET should be
+0100?
Nick van: Zulu time is not
DST-specific.
John Boyer: All xsd:dateTimes with
timezone are not DST specific. 11:00 UTC is 12:00 your time
normally.
Steven Pemberton: In the winter, and
in the summer an hour later.
John Boyer: result in CET should be
2011-12-12T12:00:00+01:00
John Boyer: And then in the
summer
Nick van: It should give +2
John Boyer: 1300, +2
Nick van: Yes.
John Boyer:
adjust-dateTime-to-timezone(2011-07-12T11:00:00Z")'
Steven Pemberton:
2011-07-12T13:00:00+02:00
Steven Pemberton: if it were a summer
date
John Boyer: If the input has a
timezone it's based on that, not now.
Nick van: Yes.
John Boyer: So if you're in your own
timezone and the user gives you this...If user is in CET and types
2011-12-12T12:00, shouldn't
adjust-dateTime-To-Timezone() in CET return
2011-12-12T12:00+01:00
Nick van: The user wouldn't enter
that; the user would use a dateTime control, or in raw format must
key in a timezone.
Alain Couthuries: [leaves]
Nick van: You can only do this
correctly if you get the timezone given.
John Boyer: Obviously we have some
spec problem. There is no different being able to do it when the
spec contains a timezone, and when it doesn't. The answer you're
giving is because that's the way it works. I'd like to give the
user a compositite control that works using this function.
Leigh Klotz: I was with you until you
got to using this function. If you let the UI decide the timezone
you win. If you don't give one it requires the XPath engine to
guesstimate it for you.
Steven Pemberton: How do we wrap
up?
John Boyer: The first example shows no
timezone and implies it works.
Nick van: We have to be careful about
specifying the timezone function; the XPath constructor doesn't do
it.
John Boyer: We should provide
feedback. When the input has the timezone attached it's doing the
same thing already to determine the output to produce. When the
input contains +1 the output on my end decides what to do based on
the input.
Leigh Klotz: Then it doesn't know when
you did it if you don't have a timezone.
Nick van: John wants it to take into
account when the date is, not when the conversion is called. Right
now you get the TZ of the constructor, and John wants it to get the
TZ of the date.
Leigh Klotz: There is a one-hour
ambiguity when the times repeat at 2:00 AM during the
changeover.
John Boyer: You have that same
ambiguity if someone provides the timezone.
Leigh Klotz: No, you don't because the
timezone is specified.
Steven Pemberton: How do we go
forward?
John Boyer: The spec shows the
function works and I want to make sure when I make it work it works
in other implementations. It is implementable but may not be what a
constructor from another group is doing. I am asking for
consistency here. It would be nice to get the word out that this
works or if we decide an erratum is needed that would be terrible
and I'd like to know soon.
Steven Pemberton: You're suggesting we
clarify the spec?
John Boyer: No, it's pretty clear the
function is supposed to return the value. Does anyone feel the spec
is wrong? If not, fix the implementation at the appropriate
priority.
Steven Pemberton: So the spec is OK
but implementations are wrong?
John Boyer: I want it to be clear that
it takes care of when it goes in and out of DST. I'm not sure
there's anything else to be done unless someone thinks the spec is
wrong.
Steven Pemberton: So no changes and
raise awareness among implementors?
John Boyer: And maybe some feedback to
the other group.
Steven Pemberton: Let's wrap it at
that.
Nick van: We should ask how the XSL WG
thinks and if they have another interpretation.
Steven Pemberton: Who wants to do
that?
John Boyer: I'd like to know how they
recommend we implement this function in the no-timezone case to
adjust consistently. When the input does have a timezone it adjusts
consistently according to the datetime in the input. So why not
when it doesn't have a timezone? If not, any guidance on how to
implement this?
Steven Pemberton: Who will do
that?
John Boyer: I don't have 100% access
to the constructors that are causing the problem in the first
place.
Nick van: They are defined in the
schema spec.
John Boyer: I don't care enough about
going off to some other group; I just want our function to behave
correctly. It's like asking the DOM group to change to be like
XPath. We just should change our function.
Steven Pemberton: Sounds like no
action needed.
John Boyer: OK.
John Boyer: I updated the Wiki for
next week.
Steven Pemberton: Next week