W3C Forms teleconference June 8, 2011

* Present

Nick van den Bleeken, Inventive Designers
Steven Pemberton, CWI/W3C (chair)
Leigh Klotz, Xerox (minutes)
Alain Couthuries, AgenceXML
John Boyer, IBM

* Agenda


* Previous Minutes

* adjust-dateTime-to-timezone

http://lists.w3.org/Archives/Public/public-forms/2011May/0029.html http://lists.w3.org/Archives/Public/public-forms/2011Jun/0015.html http://lists.w3.org/Archives/Public/public-forms/2011Jun/0014.html

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

* IRC Minutes


* Meeting Ends