- From: Jim Ley <jim.ley@gmail.com>
- Date: Wed, 16 Jun 2004 17:52:05 +0100
On Wed, 16 Jun 2004 16:29:13 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote: > > On Sun, 13 Jun 2004, Jim Ley wrote: > > > > With dates and times why the restriction on UTC? > > Only with the "datetime" type is there that restriction; it is intended > specifically to cater for the situations where a time-zone-defined time is > needed. Right, so not much use at all really then, seen as we generally have timezone dependant dates for almost all internet use. I want to know when my train arrives in London if I leave today. Seen as we can't have the legacy clients deal with the timezone issues, and we add a dependance on the client knowing the UTC offset of the user I think it's all rather over-specified and un-implementable. [flight example] > Indeed. For this use, the "time" type is available. So we cannot use the datetime control for travel sites? Rather inconvenient is it not? > Truncated representations don't seem like they would require much in the > parser. You just set anything you haven't read yet to zero. You seem to be mis-remembering ISO 8601, the truncated representations don't default to 0. Maybe a quick refresher course, perhaps you could assign an Action to one of the other working group, they don't seem to be doing much work on the spec. > > week: one of the more popular uses of weeks in the UK is the tax week, > > this of course doesn't work as an ISO8601 week, could the week widget be > > generalised so it can be used for these other definitions of week? > > Possibly; how would you do it? (I don't know enough about the UK Tax week > to know exactly what needs generalising.) The date that is week 1. > > Why are +0 etc. invalid? The MUST restriction on the UA to not submit > > numbers in invalid formats is required why, surely SHOULD is more > > appropriate? > > It has to be "MUST" so that servers are guarenteed to always be able to > parse the result. Why would it be "SHOULD"? Because of the over-validation suggestions I've talked about before on the list, servers cannot rely on the format being returned, since servers cannot rely on a Web Forms 2.0 client. > > Will there be any methods for a form requesting values not directly > > representable in your required submission format (such as 1/3)? > > Not in this version, but what did you have in mind? A method for requesting numbers not representable in your format... as to how it might look, I have no idea yet, I've not really thought about it. > Yeah. I've dropped "tel" for now. Good, 1 down, how many more features do I have left? Jim.
Received on Wednesday, 16 June 2004 09:52:05 UTC