[prev in list] [next in list] [prev in thread] [next in thread] 

List:       php-general
Subject:    Re: [PHP] [RFC] HTTP timezone
From:       Stefanos Harhalakis <v13 () priest ! com>
Date:       2007-06-09 18:17:55
Message-ID: 200706092117.56179.v13 () priest ! com
[Download RAW message or body]

On Saturday 09 June 2007, Stut wrote:
> Stefanos Harhalakis wrote:
>> I meant people using PHP to write programs also. I would dispute your
>> assertion that the majority of dynamic web pages are written in PHP. I
>> would accept an assertion that PHP is one of the most widely used
>> languages for web development.
>
> But this is all more off-topic than your original request.

Should we stop CCing the list?

> >> However, I like the idea but would modify it slightly such that it send
> >> an RFC 2822 formatted date which will include the timezone but would
> >> also allow the server to determine if the datetime on the client is
> >> wrong. This can be important for applications that make extensive use of
> >> client-side technologies such as Javascript.
> >
> > I've already thought about providing the full time but I didn't find any
> > applications. Can you provide some examples about its usage? How can you
> > tell whether a user has wrong time and not wrong timezone?
>
> You can't. But just because we can't immediately think of a use doesn't
> mean uses don't exist.
>
> Now, to the point. Including the time would only slightly modify RFC
> 2616 which states that "Clients SHOULD only send a Date header field in
> messages that include an entity-body, as in the case of PUT and POST
> requests, and even then it is optional" (section 14.18).
>
> I don't know the reason for that clause excluding other requests, but
> you would be well-advised to find out why before submitting your RFC. In
> any event, adding a new header seems daft to me when there is an
> existing header that is currently acceptable in certain cases that
> includes the information your new header would provide.
>
> In my opinion your RFC should recommend that "Clients SHOULD send a Date
> header with every request unless the client does not have a clock. A
> client without a clock MUST NOT send a Date header field in a  request."

I don't know the reason either but I'll ask the http-wg mailing list about it. 
As for the date, since HTTP1.1 covers this, an RFC that overlaps with it will 
not be accepted. Apart from that, it would need an RFC that would obsolete 
RFC2616 which I'd preffer not to do. Most probably we will need a new HTTP 
version since this will produce an incompatible protocol.

As for the usage of client Date/Time information, as a programmer I know that 
I'd never use this at the server side because of errors and malicious usage. 
Knowing the clients time isn't something usefull since the server side 
already knows it, assuming that the client has correct time. If the client 
side has an incorrect clock setting the why should one use this? Even if 
there is a reason, I believe that javascript would fit this need.

Finally, modifying the Date field to include the clients timezone offset would 
result once again in an incompatible protocol.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[prev in list] [next in list] [prev in thread] [next in thread]