Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49871
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.20.132 cause and error)
Message-ID: <4CAAD4EF.9040907@lsces.co.uk>
Date: Tue, 05 Oct 2010 08:34:07 +0100
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100714 SUSE/2.0.6-2.3 SeaMonkey/2.0.6
MIME-Version: 1.0
To: PHP Internals <internals@lists.php.net>
References: <4CA6885F.3040709@sugarcrm.com> <alpine.DEB.2.00.1010031928290.2461@kossu.derickrethans.nl> <4CA910FD.1040900@sugarcrm.com>
In-Reply-To: <4CA910FD.1040900@sugarcrm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] rfc2616 datetime format?
From: lester@lsces.co.uk (Lester Caine)

Stas Malyshev wrote:
>> The reason is that in order to format a DateTime object as GMT, it needs
>> to be converted to GMT... and you can't simply do that with just a
>> constant consisting of a string of format characters.
>
> I see what you mean and it makes sense, having constant may imply that
> you can use it with any date and get proper result... But RFC2616 is the
> one of the most used formats on the Web - actually, the format that is
> called COOKIE is not the one that should be used in cookies - RFC2616
> should be used instead. COOKIE one uses T, which may or may not be GMT,
> depending on the date and local system settings. Maybe we should have
> proper RFC format too, accompanied with appropriate warning that you
> should use it with GMT dates (or gmdate())?

There are a number of competing requirements from dates, relating to the core 
problem of not ACTUALLY having a usable flag from remote users as to their 
actual time zone ( DST information not supplied by browser ;) ). So the only 
thing that can be guaranteed is a GMT date/time, and it is that which I now use 
in the database for ALL stored timestamps. Displaying that information as a 
'local' time is rather hit and miss depending on how you identify 'local', so 
timezone while being bundled into the 'date', is a totally independent element 
and often while the offset NOW may be right, displaying GMT time for an earlier 
'stamp' may be an hour wrong if the user DST can not be identified?

If your application is using date/times that are not gmt based, then you have to 
then manage the problem of comparing times which may have an hour difference on 
the day following a DST change. but most sites seem to assume that the server 
local time is an acceptable base, which then DOES cause a problem when supplying 
time information to remote users?

SO while the 'format' of the printout is well documented, converting the 
supplied data is a separate problem?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php