Re: Re: cvs: php-src / NEWS /ext/datephp_date.c php_date.h/ext/date/tests bug26198.phpt
bug29585.phptdefault-timezone-2.phpttimezone-configuration.phpt

So, you can give precedence to the ini option over the TZ var. That way you don't need the functions. IMHO this is the better choice, as it allows you to set a site wide ini option, without touching in the environment vars or having to call a function in each script.

If there was not a BC problem then we should simply forget the ENV TZ variable. It's not reliable, not cross-platform and maybe even not TS (not sure about all SAPI). About TZ setting precedence, I see 2 needs: 1) Global or per host setting (ie vhost) 2) User defined per app 1) has precendence over TZ env and 2) over 1).

The problem is that this isn't true. Global or per host settings must be defined using the ini option, which has less precedence than TZ. The order is: timezone_set() function, TZ, ini option, magic guess, and falback as "UTC".

I do not remember if ini_set is disabled in safe_mode or if only some settings are disabled. If ini_set itself is disabled, we need this function.

I don't use safe mode, but I think ini_set() isn't disabled.

About the names, I would like to go with date_default_timezone_set and _get. Upcoming (not 5.1) features will have TZ per date resource.

That means we won't have the 'date' resource for PHP 5.1, right? Nuno