Sanford Whiteman wrote:
I'm not talking about storage time zone; we use UTC for that. I'm talking about the default display time zone. Unless we are misunderstanding each other (not unlikely given how this thread has sprawled) you seem to be saying the display time zone should be UTC by default and changed only based on end-user input. I think there are five legitimate levels of consideration (storage tz, sitewide display tz, domain/corporate display tz, stored user profile tz, and transient session tz).
Actually I probably am saying 'default to UTC for display' but simply drop the 'UTC' bit altogether! If you want a site to run in a single timezone, then using timezone settings just complicates things. In particular when trying to set a meeting in 6 months time which is the one that caught me out initially. Simply using a raw unadulterated time is the safest way of managing sites that have no real interest in daylight saving. As soon as you NEED to manage timezones/DLS, then the starting point is always to run the server as UTC and manage everything else from that. Running the server on any other setting and trying to store UTC data introduces yet another unnecessary complication.
Adding tz as a requirement was the basic mistake here. It has no place on many systems.
-- 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
