On 6/11/07, Stefanos Harhalakis <v13@priest.com> wrote:
> On Monday 11 June 2007 00:35, Richard Moore wrote:
> > On 6/9/07, Stefanos Harhalakis <v13@priest.com> wrote:
> > >  I'm currently writting and Internet Draft candidate to describe an HTTP
> > > header that will be used to transfer timezone information from browsers
> > > to servers. Compliant browsers will need to send a timezone string:
> > >
> > > Timezone: +0200
> > >
> > > that will specify their timezone offset. This way scripts will be able to
> > > provide appropriate date/time strings/representations and/or content.
> >
> > This information is already available to client side script through
> > javascript. Is it really that important the information be available
> > on the server side?
>
> First I want to thank you a lot for your reply,
>
>  I believe that Timezone information is just like the Accept-Language. It is
> meant for correct data representation to the clients. I'm writting some web
> apps and I always have the need for correct time representation to the
> clients. For example, I've written an mrtg like utility that draws graphs.
> Those graphs are completely useless for people outside my timezone since the
> displayed time is incorrect.

I can see some advantages here, though it is possible to deal with
this already by having a client side script pass that information to
the server side code. This can be done using XMLHttpRequest or simply
using request parameters then stored in the server session. That said
when I considered this for a project recently we decided against it as
it means communications between users in different countries can be
confusing as they see the time in their local timezone.

>
>  Other uses are simple time representation on web pages and other means. Lets
> say that you have a web based fax sending machine that faxes uploaded
> documents to a telephone number you enter. What time should the fax message
> have printed on it?
>
>  Finally, I don't believe that javascript should be used for things like
> this. I see the TZ header as a better (and accessible (as in accessibility))
> solution to an existing problem.

Please could you explain why you think this is a better approach than
the one above? It is certainly simpler, but as Bert pointed out it
adds overhead to all requests and it seems to be a fairly unusual
requirement. In the case of the AcceptLanguage header, the information
is obviously required in all cases which isn't true of timezone
information.

Cheers

Rich.

>
>  I'll be glad to hear your comments on this!
>