Subject: [RFC] HTTP Timezone - rev4

From: Stefanos Harhalakis <[email-masked]>
Date: Wed, 13 Jun 2007 00:37:43 +0300

After considering all feedback, I've changed the TZ information a lot.

The attached draft contains all changes. It is not yet submitted as a draft.

I changed the format of the timezone header to:

client-timezone  =  "Timezone" ":" tzdescr
tzdescr          =  rfctime [ ";" posixtz [ ";" tznames ] ]
rfctime          =  <local time>
posixtz          =  <a POSIX 1003.1 timezone string>
tznames          =  tzname *( "," tzname )
tzname           =  <a timezone string from a timezone database>

There are 3 parts now that contain the current time, the current time offset, 
the posix timezone string and a list of timezone names.

It seems that there is a variety of different needs regarding the client 
timezone. Timezone information can be described in 3 ways:

* Current time offset: This only applies to the current moment.
* POSIX timezone string: This one is able to describe the current year's 
timezone information. Previous or future years may have different DST 
settings.
* Timezone name: This is a name from a timezone database (if available). A 
timezone database is able to hold all past DST changes and some for the 
future.

I also added a section that discusses timezone issues and all rationale behind 
this.

This revision was produced using xml2rfc (previous were written using nroff).

As always, all comments are welcome!

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 13 Jun 2007 10:12:56 +1200

Just a couple of comments.

There are a proliferation of date/time formats, including ones with TZ 
information.

I think there will be more people out there that have to code 
implementations for things that have existing code for an RFC2822 style 
date/time format than for a POSIX one.  Any particular reason for the 
choice of the POSIX format?

The timezone part you have defined containing an offset from UTC + an 
optional list of timezone names (how many timezones can one UA be in 
anyway?).  The TZ offset is contained in a date field, and the timezone 
name seems to duplicate locale information which is also sent in other 
headers.

If a server wishes to use the timezone as a parameter to generate 
content, then surely it needs a method of ensuring it gets the information?

I.e. do we need a status code like "4xx Date field required" whereby the 
server can indicate that it can't generate content without the timezone 
information.

in which case why not just use the existing Date header, or expand this 
concept to encompass the complete definition of the locale of the user, 
not just timezone.

Just my 2c

Adrien

---

From: Stefanos Harhalakis <[email-masked]>
Date: Wed, 13 Jun 2007 11:33:42 +0300

> choice of the POSIX format?

There is no reason. I just thought that POSIX format is easier to parse. I've 
no objection in using the RFC2822 timezone format. I'll send another version 
using the RFC2822 format.

> name seems to duplicate locale information which is also sent in other

AFAIK there is no standard for timezone names. They depend on timezone 
databases which are client specific. The idea of a list of timezone names is 
that web clients may try to support multiple such databases. The list of 
names will be a list of known names for the same timezone.

Also, timezone is not related to locale. I'm using english locale but I have 
Europe/Athens timezone. Other countries cross more than one timezones etc.

> content, then surely it needs a method of ensuring it gets the information?

I'm thinking the whole thing as a best effort attempt to provide better 
content. Clients that don't support it will experience the current behaviour 
of seeing time related content using the web server's timezone.

> server can indicate that it can't generate content without the timezone

I believe that appart from the implementation complexity that this one 
introduces, the 'required' is the main difference. Since the idea is to 
provide a best effort service, there should be no requirement for it.

> concept to encompass the complete definition of the locale of the user,

The date header forces the client to sent its time in UTC. As far as I 
understand, this change whould need a new version of HTTP.