Re: [PHP-DEV] Local time zone
On Tue, 13 Dec 2011, Oleg Oshmyan wrote:
Which is why a pseudo-timezone called System is needed so that guesses
do not have to be made. The extension would then convert
/etc/localtime to its internal time zone description format or just
use system-provided APIs as it used to do before PHP 5.1 if I
understand correctly.
That's a really bad idea, as we've discussed before on this list.
snip
Perhaps I am a bad searcher; I would appreciate if you pointed me at
some of the past discussion.
http://marc.info/?t=11998882371r=1w=2 is what it was I think.
Thanks. The thread was an interesting read but my suggestion is different
from the one discussed there: I propose adding _one_ special time zone
that will use the /etc/localtime file or system-provided APIs (only that
time zone!), not using the /usr/share/zoneinfo directory instead of the
built-in time zone database. So existing code would work just as before
but in addition one could write
I suggest you lobby distributions that bundle PHP to add a post-install
script for dpkg-reconfigure tzdata to drop a datetime.ini file in
/etc/php5/conf.d with as contents date.timezone=newly selected
timezone. Using the information from /etc/localtime is *not* enough as
you can't get the timezone identifier out of it.
date_default_timezone_set('System');
and get direct access to the system's own notion of local time, so e. g.
date_default_timezone_set('System');
echo date('r');
would be equivalent to the C code
char date[256];
time_t now = time(NULL);
strftime(date, 256, %a, %d %b %Y %H:%M:%S %z, localtime(now));
fputs(date, stdout);
That will never happen. The whole idea with the new support is to get
*away* from OS idiosyncrasies and not adding more of them! PHP needs to
be able to rely on its own bundled timezone database. Parsing files on
the filesystem is slow and silly.
Finally, a word on removing support for the TZ environment variable in
particular: once again this makes good sense for server-side software but
is bad for client-side software, as TZ is a standard way of telling
software you launch which time zone you want it to work in.
TZ key values are not identical among operating systems, so that doesn't
work.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local time zone
On Wed, Dec 14, 2011 at 11:26 AM, Derick Rethans der...@php.net wrote: That will never happen. The whole idea with the new support is to get *away* from OS idiosyncrasies and not adding more of them! PHP needs to be able to rely on its own bundled timezone database. Parsing files on the filesystem is slow and silly. And last but not least, it is not portable at all. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC]Call for voting about const array/string dereference
On Tue, Dec 13, 2011 at 9:59 PM, Pierre Joye pierre@gmail.com wrote: On Tue, Dec 13, 2011 at 2:37 PM, Patrick ALLAERT patrickalla...@php.net wrote: 2011/12/13 Nikita Popov nikita@googlemail.com: This can't go into PHP 5.4.0 in any case, because it is a feature addition and the release is already in RC. +1 @Laruence Can you remove the voting widget? I would reset the vote and make the vote for this change to apply to trunk instead. There is no reason to delay this decision, even if it is too late for 5.4 :) Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org Hi, done, now only voting for trunk :) thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC]Call for voting about const array/string dereference
post again as a top thread with this point being clarified please :) On Wed, Dec 14, 2011 at 12:19 PM, Laruence larue...@php.net wrote: On Tue, Dec 13, 2011 at 9:59 PM, Pierre Joye pierre@gmail.com wrote: On Tue, Dec 13, 2011 at 2:37 PM, Patrick ALLAERT patrickalla...@php.net wrote: 2011/12/13 Nikita Popov nikita@googlemail.com: This can't go into PHP 5.4.0 in any case, because it is a feature addition and the release is already in RC. +1 @Laruence Can you remove the voting widget? I would reset the vote and make the vote for this change to apply to trunk instead. There is no reason to delay this decision, even if it is too late for 5.4 :) Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org Hi, done, now only voting for trunk :) thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local time zone
I suggest you lobby distributions that bundle PHP to add a post-install script for dpkg-reconfigure tzdata to drop a datetime.ini file in /etc/php5/conf.d with as contents date.timezone=newly selected timezone. This is a good idea (or perhaps exactly the opposite, as I explained in my previous email, but still needed if PHP drops all and any support for system-provided local time), but sometimes people use local copies of PHP instead of system-wide ones or their systems do not come with PHP at all. Using the information from /etc/localtime is *not* enough as you can't get the timezone identifier out of it. The time zone identifier would be System. No need to extract one from /etc/localtime. That will never happen. The whole idea with the new support is to get *away* from OS idiosyncrasies and not adding more of them! PHP needs to be able to rely on its own bundled timezone database. Parsing files on the filesystem is slow and silly. Why is it bad to have this as added functionality? Why are you worried about PHP's ability to rely on its own bundled time zone database? Let me explain my idea once again: I propose **leaving all existing functionality alone** and **adding a new time zone** called System. * All existing time zones will work as they do in PHP 5.4 RC3. The internal time zone database will be used, the internal timezone-aware code will be used and the system will not be consulted at all. Any PHP code using existing time zones will remain perfectly portable across all PHP installations. * date_default_timezone_get will work as it does in PHP 5.4 RC3. Perhaps there is confusion because I initially proposed restoring the guessing algorithm, so let me make this clear: this is a separate suggestion. So, once again: date_default_timezone_get will work as it does in PHP 5.4 RC3. * There will be a new time zone called System. When this time zone is active, instead of PHP's internal time zone database and timezone-aware code, system-provided local time APIs are used. In previous emails, I said things like 'system-provided local time description and/or APIs' but they seem only to increase confusion, so let me drop that part. This System time zone will obviously have some system-dependent behaviour, share the system's idiosyncrasies etc. but this is *the whole point*: if the programmer wants them, they should be able to get them. We have two extremes: portability across systems and blending in with the current system; just like there are two extremes in GUI design: the same GUI being used on all platforms is good because users of the software can freely switch between platforms, but having the common look and feel of the platform the software is running on is good because users of the platform feel at home. PHP's time zone functionality currently forces the programmer to be at the portability extreme; my suggestion is to let the programmer choose which extreme to be at. (The reasoning for 'system-provided local time description and/or APIs' was that it might be easier to implement some functions by converting /etc/localtime to PHP's internal representation and using PHP's existing internal timezone-aware code than by making a new code branch that calls into the system. As for restoring the guessing algorithm, I suggested that merely as an easier alternative to making a whole new time zone that consistently uses system-provided APIs.) -- Oleg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local time zone
Hi! * There will be a new time zone called System. When this time zone is active, instead of PHP's internal time zone database and timezone-aware code, system-provided local time APIs are used. In Which APIs do you mean? I imagine it might be possible (note - just might be, no guarantees here) to get the system TZ data and use it in similar manner to existing TZ data if the formats are suitably close and all the info is available. However if you mean using actual system functions in parallel with timelib functions, that's probably not going to happen - there's too many problems with using two APIs simultaneously to do the same thing, not talking about portability, etc. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local time zone
I believe he's referring to sys/time.h, but this introduces portability issues. If it were just unix, that would be one thing. But maintaining this and a Windows alternative, and I have no idea what that is, is not worth it IMO. On Dec 14, 2011, at 4:29 PM, Stas Malyshev wrote: Hi! * There will be a new time zone called System. When this time zone is active, instead of PHP's internal time zone database and timezone-aware code, system-provided local time APIs are used. In Which APIs do you mean? I imagine it might be possible (note - just might be, no guarantees here) to get the system TZ data and use it in similar manner to existing TZ data if the formats are suitably close and all the info is available. However if you mean using actual system functions in parallel with timelib functions, that's probably not going to happen - there's too many problems with using two APIs simultaneously to do the same thing, not talking about portability, etc. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local time zone
Hi! I believe he's referring to sys/time.h, but this introduces portability issues. If it were just unix, that would be one thing. But maintaining this and a Windows alternative, and I have no idea what that is, is not worth it IMO. Yes, portability is questionable. Though if we had a good patch that allows to do it, I don't think it would be too bad to have it. Even Unix-only might be (again, if enough people need it) fine, if we could use the data properly in timelib functions. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local time zone
On 14/12/11 22:53, Will Fitch wrote: I believe he's referring to sys/time.h, but this introduces portability issues. If it were just unix, that would be one thing. But maintaining this and a Windows alternative, and I have no idea what that is, is not worth it IMO. time.h is present in *nix, Windows, and probably everywhere php runs. As it provides mktime/gmtime/localtime, it should be possible to portably deal with timezones. At least when it's not multithreaded. And if the host doesn't contain timezone data (embedded systems, perhaps), that System zone could simply default to UTC. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local time zone
Hi! On 14/12/11 22:53, Will Fitch wrote: I believe he's referring to sys/time.h, but this introduces portability issues. If it were just unix, that would be one thing. But maintaining this and a Windows alternative, and I have no idea what that is, is not worth it IMO. time.h is present in *nix, Windows, and probably everywhere php runs. As it provides mktime/gmtime/localtime, it should be possible to portably deal with timezones. You seem to be misunderstanding what portable means here. It doesn't mean compiles and runs on each system, it means reliably produces predictable and identical results on each target system. The case with *time system functions is very far from that. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local time zone
If enough interest is in this, I'll write a patch with the expectation for unix based systems initially. I'll have to research the windows support and reliability. Who would care to have this (I personally will still be relying on ini)? Sent from my iPhone On Dec 14, 2011, at 5:44 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 14/12/11 22:53, Will Fitch wrote: I believe he's referring to sys/time.h, but this introduces portability issues. If it were just unix, that would be one thing. But maintaining this and a Windows alternative, and I have no idea what that is, is not worth it IMO. time.h is present in *nix, Windows, and probably everywhere php runs. As it provides mktime/gmtime/localtime, it should be possible to portably deal with timezones. You seem to be misunderstanding what portable means here. It doesn't mean compiles and runs on each system, it means reliably produces predictable and identical results on each target system. The case with *time system functions is very far from that. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local time zone
Which APIs do you mean? I imagine it might be possible (note - just might be, no guarantees here) to get the system TZ data and use it in similar manner to existing TZ data if the formats are suitably close and all the info is available. Yes, this is what I meant when I wrote about using /etc/localtime: convert it into the same internal representation that PHP's own time zone database uses and then just use the existing code as if /etc/localtime was just another time zone in the database. However, this is definitely not portable; at any rate Windows will not have /etc/localtime. Thus I suggested that standard library functions be used: However if you mean using actual system functions in parallel with timelib functions, that's probably not going to happen - there's too many problems with using two APIs simultaneously to do the same thing, not talking about portability, etc. Now that I think of it, the only system [library] calls that need to be made are localtime() and mktime() to convert between timestamps and the year-month-day-hour-min-sec representation, as these are the only timezone-aware operations. And localtime() and mktime() are not just POSIX but C89, so all platforms including Windows have them. Even so, the Windows implementation is of course broken (it always uses hard-coded DST rules and even seems to require TZ to be set), but doing the same operations via the Win32 API is fairly easy. I had no knowledge of this before and got this code just by looking at a couple of pages in the MSDN Library: SYSTEMTIME utc, local; convert the timestamp into a SYSTEMTIME SystemTimeToTzSpecificLocalTime(NULL, utc, local); convert the resulting SYSTEMTIME into a struct tm The reverse is similar. NULL means we want to use the current system time zone. The format conversions are straightforward but take a few lines each, which is why I omitted them. Funnily enough, the docs for SystemTimeToTzSpecificLocalTime give a corner case in which the conversion might be wrong, but (a) this is the same function that will most likely be used by other Windows software and (b) this is the best we can get, as I do not see any way to get the full time zone data with all historical information in it. You seem to be misunderstanding what portable means here. It doesn't mean compiles and runs on each system, it means reliably produces predictable and identical results on each target system. The case with *time system functions is very far from that. I think that in this case this is exactly not the best definition of portable. What we really want (what I really want) from the System time zone is that it compiles and runs on every system and on any particular system works the same way as other software on the same system does. Still, the only possible issue I see with portability in the traditional sense is the range of timestamps that the *time functions work with, which can be 'solved' by simply noting in the documentation that it is platform-dependent (as it used to be solved when the *time functions were used throughout). -- Oleg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local time zone
time.h is present in *nix, Windows, and probably everywhere php runs. As it provides mktime/gmtime/localtime, it should be possible to portably deal with timezones. At least when it's not multithreaded. PHP internally already has php_localtime_r and php_gmtime_r in main/php_reentrancy.h, implemented in main/reentrancy.c, and they are already used in various places in the code, including the guessing algorithm that is being removed in PHP 5.4. So at the very least thread-safety (and in fact portability too) should not become worse than it is now. And if the host doesn't contain timezone data (embedded systems, perhaps), that System zone could simply default to UTC. Sounds good. -- Oleg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local time zone
On 15/12/11 00:10, Oleg Oshmyan wrote:
PHP internally already has php_localtime_r and php_gmtime_r in
main/php_reentrancy.h, implemented in main/reentrancy.c, and they are
already used in various places in the code, including the guessing
algorithm that is being removed in PHP 5.4. So at the very least
thread-safety (and in fact portability too) should not become worse than
it is now.
Oh, nice. I thought thet would be doing its own argument passing, based
on timelib, but turns out they do retrive the value from the system
{local,gm}time, even on those without a _r version.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local time zone
Even so, the Windows implementation is of course broken (it always uses hard-coded DST rules and even seems to require TZ to be set) Actually it might even be fine. The relevant MSDN Library pages are worded confusingly; I will perform some tests and report back. If localtime and mktime indeed work well on Windows, I would in fact prefer them to be used, not just because that will mean less/no platform- dependent code but also because they honour the TZ environment variable like POSIX-compliant implementations do. It is worth mentioning that VC9 has 64-bit and 32-bit versions of time_t, localtime and mktime while VC6 only has a 32-bit version. Unfortunately, none of these versions work with times before 1970. -- Oleg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local time zone
Oleg Oshmyan wrote: It is worth mentioning that VC9 has 64-bit and 32-bit versions of time_t, localtime and mktime while VC6 only has a 32-bit version. Unfortunately, none of these versions work with times before 1970. Actually that is probably another discussion, but is the php date function still limited to 13 Dec 1901? Personally I still use the ADOdb date functions http://phplens.com/phpeverywhere/adodb_date_library which goes back to 100AD, and before that if you manage the 2 year date problem. For genealogical data it's also necessary to manage the calendar used which does add to the fun ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
