Re: [RFC] HTTP Timezone - rev4

On Wednesday 13 June 2007 01:12, Adrien de Croy wrote:
> 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?

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.

> 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.

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.

> 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'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.

> 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.

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.

> 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.

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.

Received on Wednesday, 13 June 2007 08:33:57 UTC