Derick Rethans wrote:
You have an accurate representation of the ISO format - which does not
>specify the string representation of a timezone, but rather the offset of
>UTC. This is not lossy.
Yes it is! You can't go back from an UTC offset to a timezone string.
Hence: lossy.
Exactly ...
Will - if you are displaying a date, and then looking for a UTC time 6 months
later you need the daylight saving setting. Personally I get around this problem
by displaying a 'local client time' based on extra details provided by the
client login. A server default is never going to be the right answer unless you
simply switch off ALL timezone working and only use local time, in which case
your proposal could work - as long as it NEVER displays offsets. Most problems
on systems that DO require to correctly manage timezone shifted data come about
by not running the server with a fixed UTC clock and then trying to map things
across different timezones. In this situation, the browser time offset is
useless and the main reason that Derick is flagging ISO format as lossy. It can
never give you the correct data in six months time where daylight saving shifts
comes in and using it here is just exacerbating that problem by continuing to
reinforce a wrong 'standard'.
So the server 'default' local time needs to work of extra timezone data rather
than the local clock. Any display MUST then show timezone rather than just an
arbitrary offset or simply UTC time ... with a UTC flag to confirm that.
--
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
