Re: [RFC] HTTP Timezone - rev4

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


Stefanos Harhalakis wrote:
> 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!
>

Received on Tuesday, 12 June 2007 22:13:03 UTC