I don't see what the time zone has to do with the date control. Can you elaborate?

A date is a (specific) range in time. Like any points of time, it's meaningless without time zone.
In the USA, it's 2.9.2009, while in Australia, it's already 3.9.2009.

Omiting the timezone is natural in our human experience, but causes huge problems when programming, because it's wrong. If the timezone is omitted, there's always a timezone implied, usually the timezone that the user is in currently. The browser is in the best position to know the user's timezone, because all current OS configure it.

A date has a time zone if it's referring to a specific 24 hour period, But a date doesn't have a time zone if it's referring to something like one's birthday. For things that are actually periods, it's more likely that it'll be a period of less than 24 hours, e.g. a meeting of one hour. In that case, the datetime control is the right one to use, not the date control.

> a date doesn't have a time zone if it's referring to something like
> one's birthday

Actually, it does. The timezone that the person having birthday is [born] in.

Please put yourself in the position that you're a company in Australia, and you have an international audience.
You allow users to specify the birthday, and you offer SMS reminders. Surely, you need to make them at the correct time, including timezone.

The user having to manually specify a timezone for every size is cumbersome and error-prone. The webserver just assuming a timezone based on IP-address is even more error-prone. The OS (and therefore browser) knows best.

s/size/site/, sorry

Please point me to a single site on the Web today that asks for a date (and not a time) and yet either asks for a time zone explicitly at the same time, or records the user's time zone explicitly with the date in question.

> asks for a time zone explicitly at the same time

That's not what I propose.

Part of my comment was: "is this communicated to the user? can he change it?"

I propose that the browser gets the user's timezone from the OS (all modern OS configure it, and many apps including NTP / the clock display depend on it).
The browser then includes it in the value that is sent to the server.
That does not mean that it's displayed to the user. In fact, I assume it's *not* shown to the user.

The browser *may* offer the user a way to specify the timezone, though, for the rare case where the user wants to override it.

But even though it's rare that the user derives from his timezone, it's common that different users of a site are in different timezones, and the site *must* account for that, or things will go wrong.

Current sites either assume the timezone from the IP address of the user, or allow/require him to configure it in prefs. That's very cumbersome.

Could you show me a site that asks for a date, but uses the user's time zone at the time of form submission (as opposed to at the time of display) in its interpretation of that date?

Any calendar, reminder, booking etc. site.

> as opposed to at the time of display

The problem may be that you think of a date as a string (to display). It's not. It has a *meaning*. A date is a point (or range) in time, and may be acted upon by the site/server. Please go back to comment 5 and think through it from the perspective of the server programmer.

(In reply to comment #10)
> Any calendar, reminder, booking etc. site.

I looked at a bunch, and I couldn't find any sites that asked for a date only (no time) and yet used the 24-hour period corresponding to the user's submission time zone, and not the date irrespective of time zone. Could you provide a URL to one explicitly that I could look at?


> > as opposed to at the time of display
> 
> The problem may be that you think of a date as a string (to display). It's not.
> It has a *meaning*. A date is a point (or range) in time, and may be acted upon
> by the site/server. Please go back to comment 5 and think through it from the
> perspective of the server programmer.

I understand that the date has meaning. I just don't think sites are doing what you think they're doing. I think the use case for a date control doesn't need a time zone in practice.

For example, Google Calendar uses a date control only for events that are time-zone agnostic — if I set an event to be on Thursday October 22nd 2009 while my time zone is UTC+12, and then change my time zone to UTC-12, the event still claims to be on Thursday, even though there are no minutes in common for those two events.

For timezone-dependent events, sites have date+time controls, which is type=datetime.


EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: I do not believe the use cases match what you describe.

Please provide an example of an event that has no timezone associated.

Periodicals like Christmas don't count, because they don't have a year.

Examples of dates with timezone:
* An all-day event
I have an all-day meeting or festival in Berlin. It's in the Berlin timezone. If I don't specify a timezone, it's the timezone I am in (because most my events are geographically near me, for practical purposes). *My* timezone is a different timezone from another user, though.
* My parents are on vacation.
The timezone my parents are in.
* A deadline
Mozilla tree closure at 2009-10-29
Firefox 3.7 release at 2009-11-20.
Both are in PDT timezone.

You still have not responded to the case described in comment 5.

Other example:
A calendar site allows to find free time of other users, to schedule events. The other user has an all-day event planned. I need to compare my time with the all-day event. But I don't know the time zone the latter is in!

In Google Calendar, you have to specify your time zone. That should be unnecessary! A user should not be bothered with time zones, unless he actually jumps between them. Yet, the site needs to know the timezone for all time/date specifications, for the reasons above.

I've struggled too many times with not having the timezone and needing it, although it was not obvious to the programmer who created the data source. He just assumed a timezone, like "the timezone of the user", and I didn't know which the timezone of the user is and needed to compare.

If you just WONTFIX all comments that don't match your viewpoint, the spec can't improve from other viewpoints!

> Please provide an example of an event that has no timezone associated.

All-day events in Google calendar.
Departure dates on sites like Expedia.
Porn sites that ask for birthdays.
Flower delivery sites.
Basically any time a site asks for a date only, and doesn't ask for a time, they don't want a timezone associated with it.

You haven't provided a single URL to a site contradicting this as far as I can tell.


> Examples of dates with timezone:
> * An all-day event
> I have an all-day meeting or festival in Berlin. It's in the Berlin timezone.
> If I don't specify a timezone, it's the timezone I am in (because most my
> events are geographically near me, for practical purposes). *My* timezone is a
> different timezone from another user, though.

No, in practice, this is incorrect. Calendars have 24-hour-long events (type=datetime for the start, type=datetime for the end) and day-long events (type=date). The former have time zone information, the latter do not, and are displayed somewhere quite different on the display, even when the two users are in time zones with almost no overlap (e.g. Australia and Hawai'i).


> * My parents are on vacation.
> The timezone my parents are in.
> * A deadline
> Mozilla tree closure at 2009-10-29
> Firefox 3.7 release at 2009-11-20.
> Both are in PDT timezone.

All of the above are examples of precise times, not dates, and one would use type=datetime, not type=date.


> You still have not responded to the case described in comment 5.

If you want to schedule a reminder, you don't ask for a date, you ask for a time.


> Other example:
> A calendar site allows to find free time of other users, to schedule events.
> The other user has an all-day event planned. I need to compare my time with the
> all-day event. But I don't know the time zone the latter is in!

In practice, this is not how calendars work as far as I can tell. Certainly, Google Calendar makes a distinction between all-day events (which are timezone-less dates) and 24-hour events (two datetimes with timezones).


> If you just WONTFIX all comments that don't match your viewpoint, the spec
> can't improve from other viewpoints!

I am not basing this on my viewpoint. My viewpoint, actually, is that we shouldn't have time zones at all, and we should all use UTC, and that all data should be defined relative to UTC, and that the spec therefore should just define everything as relative to UTC. My viewpoint is irrelevant here.

I'm basing this on use cases.

Please feel free to escalate this if you still disagree.

> You haven't provided a single URL to a site

How can I provide a URL to a site using a feature that does not exist?

The idea here is to make timezones explicit in system, but transparent to users. Users don't need to bother with them, still they are always correct. No guessing from programmers/servers.

Current websites ask you to provide your timezone in prefs, because we have proper date/time handling on the web yet.

> > The timezone my parents are in.
> > Firefox 3.7 release at 2009-11-20.
> > Both are in PDT timezone.

All of the above are examples of precise times, not dates, and one would use
type=datetime, not type=date.

In practice, please express them by date. Microsoft says a software is going to be released on Tuesday, and the German press reports it as such, but Microsoft implicitly means PDT, and I notice only when I wait all day and nothing happens.

When I schedule the vacation of my parents in the calendar, I use all-day events.

> In practice, this is not how calendars work as far as I can tell.

See above. Current websites are limited by date strings plus user prefs.

> > You still have not responded to the case described in comment 5.

> If you want to schedule a reminder, you don't ask for a date,
> you ask for a time.

You didn't take my case. I picked up your birthday case, and explained it. You don't use a datetime for birthday. Yet, birthday reminders are not uncommon, and they do need a timezone information, because the reminder needs to happen at a certain real-world *time*, although the user entered only a *date*. Ergo, you need a timezone.

> Please feel free to escalate this if you still disagree.

How?
Yes, I think this is a clear and giant mistake, and will lead to serious problems. Not more than we already have, but much more than we could have.

Sites are quite capable of having date pickers today, they just do so using JavaScript (or even a <select>) instead of the <input> element. For example, here is a site that doesn't do what you describe:

   http://flowers.com/

It has a date picker (currently using a <select> widget), and there is no time zone information included at any point in the process.

Comment 11 details the escalation procedure.

> Sites are quite capable of having date pickers today, they just do so using
> JavaScript

But JavaScript can't access the timezone information from the OS.

(If there's an obsure way, e.g. via HTTP headers, I don't think authors have figured that out yet.)

> It has a date picker (currently using a <select> widget), and there is no time
> zone information included at any point in the process.

Again: I am *not* proposing that the user enters the timezone manually (at least not in any usual case), but the browser silently fills this in, in the background.

> But JavaScript can't access the timezone information from the OS.

new Date().getTimezoneOffset()


> > It has a date picker (currently using a <select> widget), and there is no time
> > zone information included at any point in the process.
> 
> Again: I am *not* proposing that the user enters the timezone manually (at
> least not in any usual case), but the browser silently fills this in, in the
> background.

My point is that the sites that use date pickers don't even do that.

I am convinced that this will cause serious problems. Any time when timezones have been ignored in an API, it later turned out to be a serious headache.

> My point is that the sites that use date pickers don't even do that.

They may not have run into the problem yet, or solve it differently, or they make silent assumptions.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale:

Please show me a site that makes such an assumption, or that solves it in a different way that is incompatible with what the spec does.

If _no_ site has run into this, then fixing it in the platform seems premature. We wouldn't have any experience in fixing it to know what fixes actually work. If some site has run into this, then please provide a URL to that site so that I can examine their solution.

Please do not reopen the bug without new information. If you have no new information to provide but still disagree, please escalate the bug as described in the paragraph at the top of this comment.