On 26/05/13 13:50, Lester Caine wrote: > Richard Quadling wrote: >> As more and more site/services are being hosted in the cloud, allowing >> requests to be handled locally geographically, in different >> timezones, does >> it make ANY sense in setting a timezone at all other than UTC? > > This is something I have been saying all along. The whole thing is > broken anyway since you have no idea what time-zone a USER is > accessing from since the browser bodge only provides a current time > offset. Until a user logs into a site and provides the data of their > current daylight saving 'location' anything else is a guess. 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? >
If you're writing a CLI script which produces timestamped log lines on stdout, it probably makes sense to use the TZ environment variable, and to fall back to /usr/share/zoneinfo if it is unset, like localtime(). If you're writing a web app which writes timestamped log lines to a local file, it probably makes sense to use whatever timezone is specified in /usr/share/zoneinfo, for consistency with syslogd etc. For timestamps sent to web app end users, you probably want it to be user configurable with UTC as the default, or use some local time for websites with geographically limited interest. It's likely that the timezone of maximum user interest will be different from the server timezone, so it doesn't really make sense to couple the two. In none of these cases does it make sense to require the sysadmin to set a timezone in php.ini before even being able to use the app, so I don't understand why that is the policy chosen by PHP. But like I said in my original post, I really don't mind: thank you for writing ext/datetime, please continue annoying users to whatever extent you see fit. -- Tim Starling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
