On Mon, 4 Jul 2005 11:48:06 +0100 "Nuno Lopes" <[EMAIL PROTECTED]> wrote:
> >> 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". Exact, in my opinion this is not a good thing. We may break BC here. TZ env is everything but not portable (even not in unix world), meaning that the order should be: timezone_set, ini, ENV, 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. Will test :) > > 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? I do not think I will have the motivation or the time to do it for 5.1, but I think there is no question as 5.1 features are freezed. My first thought was to have a separate new set of date/time functions. Doing so we do not break any existing applications and we were able to do the right choices. See my early posts about that here: http://marc.theaimsgroup.com/?l=php-dev&m=104540995515576) For now I will focus on my pecl work. I suspended my commits and my new things on Derick's demand, was maybe not a good idea, but it's too late now ;). The only thing I will use from timelib is the TZ database. But it needs to be editable, allows aliases. Aliases are important to keep the database consistent with the original Olson's version. If not we are just going to maintain "yet another custom TZ DB", and this is no good idea. As far as I remember, Derick agreed to add aliases support later. Regards, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
