> Until a user logs into a site and provides the data of their current > daylight saving 'location'
Which we might as well assume will never happen. I know our users don't waste time on this step if it's optional, and I'm not going to push an E_FATAL onto them by saying I'm not going to show them timestamps at all unless they set their TZ. Nor am I going to make them see stuff in UTC, because they'll just say, "This site's borked" and laugh at us and/or assume we're in the UK and go on with their work, instead of seeking a solution. And as I note below, for us at least, the solution is not to have them set their "true" timezone. > If you are assuming a server is in a single time-zone, then it makes > even less sense to use anything other than UTC and ignore timezones > altogether? Not always, because of something Tim alludes to: principal geographic interest. We run a multi-tenant architecture, and each tenant has a home office in a US city. The time zone at HQ is typically the time zone on which work schedules/deadlines are based, and their users don't always *want* to see their offset applied as they travel to Chennai or Paris for a couple of days. They'll change their phone/watch/laptop timezone, yeah, but they're collaborating with people in the US timezone and they don't want to face constant offsets and am/pm confusion whenever they log in. Even subcontractors permanently residing in another city are usually better off with the HQ timezone, because they are racing to submit stuff by HQ's close of business, not their own (which could be three business days later). It is true that some of our tenants share the same PHP.INI, so in this respect the INI value itself is not useable, but the principle still applies. A more sensible default than UTC can usually be found using domain and corporate knowledge. For our userbase, setting to New York time by default (that's our time) still would be less confusing than UTC. US residents have an immediate grasp of the West Coast/East Coast 3-hour shift but wouldn't grok the international offsets. As Tim and Richard said, the "most interesting" timezone has no intrinsic relationship to the server timezone given cloud computing/colocation. Anyway, the problems raised on this thread have made me think more about how we let users handle time, so I appreciate the discussion and may change my take over the next few days. -- Sandy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
