Re: Date & TimeZone classes for your consideration

Ross Smith II wrote:

Why do all this? The timezone is easily available via strftime('%Z') or date('T'). Also, daylight savings is available via date('I'). Shouldn't you at least test strftime or date before assuming UTC?

On most unix systems the TZ environment is what affects strftime & date... I suppose it would probably be good to test those as well in case a system had an implementation of zoneinfo that didn't use the TZ var. With PHP_TZ and the global var, I wanted to make sure people had a way to set their PHP time zone in case their host system was misconfigured, or they just wanted to run their app in a certian zone. Daylight savings time is the trickier case. We're not only interested in DST for the local system time zone, but in getting accurate DST information for possibly 2 foreign time zones. localtime, like date and strftime uses the underlying system implementation of zoneinfo, so in order to get information about foreign time zones, we need to trick the host system into thinking its in that time zone for a second. Hence we putenv TZ to the zone we need info on and hope that makes localtime, date, etc. do what we want. The real answer is to get PHP access to zoneinfo natively, but thats a larger project. baba -- Baba Z Buehler <baba@BabaZ.com> http://BabaZ.com/ PGP KeyID: 0xA88A6D4C "Those who are willing to sacrifice freedom for security deserve neither." -Benjamin Franklin