Re: [PHP-DEV] Local time zone
On Tue, Dec 20, 2011 at 1:35 AM, David Muir davidkm...@gmail.com wrote: Isn't this whole thread about client-side apps, not server-side. For client-side stuff it doesn't make sense to use anything but the system tz. No, that's the job of the PHP application to take care of that. And that's also why system TZ is not very relevant, per se. And it is done using the datetime function, see: http://www.php.net/manual/en/function.date-default-timezone-set.php http://www.php.net/manual/en/datetime.settimezone.php Cheers, -- 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
On Tue, 20 Dec 2011, David Muir wrote: Keeping the tz database up to date is a very annoying issue. System tz data is typically more up-to-date as it's pushed to the user, while with php, you need to have admin rights to install an updated tz database, or hope that the packager for your distro (or your web-host) does it for you. Distributions should push the tzdata for PHP just like they do for Java. Nothing stops them from doing that. As far as I can tell, most hosts do not update timezone data from PECL. I just checked one host that is still on 5.2: date/time support enabled Olson Timezone Database Version 2010.9 Timezone Database internal Default timezone UTC Sigh... Ubuntu however reports 0.system as the tz version. Does that mean that PHP there is using the system's tz database instead? It means that they have a crap patch that scans the file system... and destroys some information that PHP users need to be able to rely on. 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, 14 Dec 2011, Oleg Oshmyan wrote: 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. System is not a defined Timezone Identifier. So you can never match this against anything else PHP does. /etc/localtime does not provide all the information that PHP's date/time support needs. Hint: It doesn't use OS syscalls or library calls at all. * 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. That'd mean duplicating every function that deals with timezone. As I said: not going to happen. 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, 14 Dec 2011, Stas Malyshev 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. 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. This can never be portable, because Windows doesn't even bother keeping historical timezone rules. They only have: current normal UTC offset, current DST offset and rules on when there is a transition between. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local time zone
On Wed, 14 Dec 2011, Ángel González wrote: 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's date time support does not use time.h. With one of the reasons is that time_t is 32bit on most Unices, and we need to support things outside that range too. 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
It means that they have a crap patch that scans the file system... and destroys some information that PHP users need to be able to rely on. Just as PHP users need to rely on the Olson database being present and usable, they need to rely on the system time zone being present and usable, but PHP currently refuses to let them access it. (Derick, sorry, I accidentally sent you another copy of this email.) -- Oleg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local time zone
On Thu, 15 Dec 2011, Lester Caine wrote: 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? No. Internally, it uses 64 bit integers. As long as you use the object oriented approach it will work. If you go back to timestamps, you have to rely on twhat the OS supports as integer size (which is sadly 32 bit on Windows). 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
Derick Rethans wrote: Actually that is probably another discussion, but is the php date function still limited to 13 Dec 1901? No. Internally, it uses 64 bit integers. As long as you use the object oriented approach it will work. If you go back to timestamps, you have to rely on what the OS supports as integer size (which is sadly 32 bit on Windows). Which is probably the reason I don't use anything other than the database timestamps :) While you say it uses 64bit internally. I presume that means it JUST uses 64bit numbers? Or does it actually follow the Julian calendar corrections prior to 1900 such as the Gregorian Correction? -- 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
Re: [PHP-DEV] Local time zone
Hi! This can never be portable, because Windows doesn't even bother keeping historical timezone rules. They only have: current normal UTC offset, current DST offset and rules on when there is a transition between. Well, that closes the question for Windows, but in theory we maybe could support TZ data import for Unix, right? Or there are other issues that inhibit it? -- 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
This can never be portable, because Windows doesn't even bother keeping historical timezone rules. They only have: current normal UTC offset, current DST offset and rules on when there is a transition between. Windows does keep historical timezone rules and uses them in SystemTimeToTzSpecificLocalTime, although sadly not in localtime (I have just checked on Windows XP). In case you are interested, the historical rules are stored in the registry in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\*\Dynamic DST. System is not a defined Timezone Identifier. So you can never match this against anything else PHP does. My suggestion is exactly to define it. * timezone_name_get will return 'System'. * If an abbreviation is required at all times, an arbitrary one, say, 'SYS', will do. * timezone_offset_get will calculate the offset on the fly as described below. * timezone_location_get and timezone_transitions_get are indeed not implementable, but they are not implementable for, say, the existing Factory time zone either; they could just return the same nonsensical values they return for Factory, or some new special return values. Of course the return values should be documented in any case. That'd mean duplicating every function that deals with timezone. As I said: not going to happen. No, it is enough to make the new time zone TIMELIB_ZONETYPE_ID with no leap seconds and add a branch to fetch_timezone_offset: instead of enumerating the offsets in the time zone description, it will call localtime/SystemTimeToTzSpecificLocalTime, treat the result as UTC, convert it back to a timestamp and subtract from it the original timestamp. On systems with tm_gmtoff in struct tm, it can be used as a shortcut. On UNIX, the DST status can be obtained from the tm_isdst member of struct tm and an abbreviation can be obtained from the tm_zone member or the tzname global variable. On Windows, more work is needed but ultimately both can obtained from GetTimeZoneInformationForYear. I have tried and failed to understand the in_transition logic in do_adjust_timezone, so that, or rather timelib_update_ts, may (or may not) need new code as well, but all other functions will work perfectly well with no changes. - Finally, while I was writing this and investigating the code, I noticed that strtotime does some obscure timezone-dependent preprocessing of its $now argument. Is this intended? -- 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 21:17, Pierre Joye wrote: On Wed, Dec 14, 2011 at 11:14 PM, Stas Malyshev smalys...@sugarcrm.com wrote: 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. By portability it is not (only) about APIs, APIs wrapping is easy these days, even on Windows. But the actual problem is to get a consistent and constantly updated set of data, reliable data. Data that applications can use blindly on any platforms without having to worry about bad information, as long as they use the latest PHP or timezone release (via PECL for example). And that, as stated earlier, is why we should not provide any alternative as any other solutions failed so far. It is also even less important as Oleg's target is the developer environment. If a developer cannot set his TZ correctly in a php.ini or in his application on his development box, then something is wrong there, but not in php :) For production server, I would never ever suggest to use the system's TZ, no matter the OS/distros/etc.. Cheers, Isn't this whole thread about client-side apps, not server-side. For client-side stuff it doesn't make sense to use anything but the system tz. Should we be expecting users to have to edit php.ini files every time they hop on a plane or drive across a tz border? And what about non-developers? Keeping the tz database up to date is a very annoying issue. System tz data is typically more up-to-date as it's pushed to the user, while with php, you need to have admin rights to install an updated tz database, or hope that the packager for your distro (or your web-host) does it for you. As far as I can tell, most hosts do not update timezone data from PECL. I just checked one host that is still on 5.2: date/time support enabled Olson Timezone Database Version 2010.9 Timezone Database internal Default timezone UTC Sigh... Ubuntu however reports 0.system as the tz version. Does that mean that PHP there is using the system's tz database instead? Cheers David -- 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:14 PM, Stas Malyshev smalys...@sugarcrm.com wrote: 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. By portability it is not (only) about APIs, APIs wrapping is easy these days, even on Windows. But the actual problem is to get a consistent and constantly updated set of data, reliable data. Data that applications can use blindly on any platforms without having to worry about bad information, as long as they use the latest PHP or timezone release (via PECL for example). And that, as stated earlier, is why we should not provide any alternative as any other solutions failed so far. It is also even less important as Oleg's target is the developer environment. If a developer cannot set his TZ correctly in a php.ini or in his application on his development box, then something is wrong there, but not in php :) For production server, I would never ever suggest to use the system's TZ, no matter the OS/distros/etc.. Cheers, -- 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
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] 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
Re: [PHP-DEV] Local time zone
On Mon, 12 Dec 2011, Oleg Oshmyan wrote: This might work on some distrbutions, but not nearly on all. And definitely not on Windows. On Debian it's not a symlink for example. It is still usable as one of the possibilities for the guessing algorithm to examine. Initially I also wanted to say that /usr/share/zoneinfo can be searched if /etc/localinfo is not a symbolic link, but I have just run a test: snip We will not be adding code that has to scan the filesystem. It's a guess, and that's the problem. Guessing makes up for odd and strange bugs if it's not 100% accurate (which it isn't). 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. 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
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
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);
While PHP does focus on server-side Web programming, it is not limited to
it and is a general-purpose scripting language. It can be used to run
'client-side' scripts just like the shell, Perl, Python and Ruby can be
used, and in fact it can also be similarly used to run command-line (or
even graphical) utilities on servers, and even in Web pages one might
sometimes explicitly want to use the server time. In all these cases
system time needs to be used, and the only reliable way to do so is to
refer directly to the local time zone description and/or local time APIs
provided by the system. Being independent of the system in other cases is
also important, and so adding a single special time zone that trusts the
system to the already-existing set of time zones that do not trust the
system seems not just a compromise but a win-win solution.
For now I will find where all my php.ini files are, add date.timezone and
write a script to edit them all at once when I move from one time zone to
another. I might even schedule it to run regularly and pick up changes
automatically or even make it a daemon if I was constantly travelling.
This will normally work for me even if it somewhat annoys me, but if I
forget to run my script or if I decide for any reason to move to (or
pretend I am in) some obscure time zone PHP does not know, I will easily
be able to explain that to my system, including virtually all other
software I use, but not to PHP.
Recommending server administrators to set date.timezone to provide
scripts with the ability of using the server's local time also has a
negative consequence: poorly-written software that uses local time
without caring about time zones will stop generating the warnings it
generates now. In the end this might well encourage such poor practices
more than discourage them.
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. When the
local time API used by this software supports TZ (and just about
everything supports it), it just works, without the programmer doing
further work such as adding command-line options and in fact without them
even knowing that you use this functionality. For example, I have used
this to make commits on a remote machine (in an SSH session) with commit
dates recording my local time zone instead of the (properly used!) system
time zone of the remote machine.
--
Oleg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local time zone
On Sun, 11 Dec 2011, Oleg Oshmyan wrote: * The tzname C variable can be used to get two abbreviations for the current zone (typically the standard one and the DST one for zones where DST is used), which allows to improve the guess compared to using just one abbreviation; for example, the time zone in London in winter will be guessed as Europe/London rather than UTC. It's a guess, and that's the problem. Guessing makes up for odd and strange bugs if it's not 100% accurate (which it isn't). * /etc/localtime is often a symbolic link to or a copy of /usr/share/zoneinfo/time zone identifier. In this case this time zone identifier can be considered another candidate just like the values of date.timezone and TZ. This might work on some distrbutions, but not nearly on all. And definitely not on Windows. On Debian it's not a symlink for example. * This requires more effort, but ideally PHP should just have a special time zone named something like 'System' that would use /etc/localtime instead of any built-in time zone data, just like the localtime C function does when the TZ environment variable is empty. That's a really bad idea, as we've discussed before on this list. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local time zone
On Dec 11, 2011, at 1:07 PM, Pierre Joye wrote: hi, On Sun, Dec 11, 2011 at 1:59 AM, Oleg Oshmyan chor...@inbox.lv wrote: I am willing to work on patches but I suppose some consensus should be reached first. The consensus was that you have to set a valid default timezone in php.ini I feel there may be a lot of value for people being able to install PHP applications and run them without any additional configuration. What would be the recommended way to have PHP reflect the systems timezone? I like the PHP 5.4.0 behaviour of defaulting to UTC if it's not setup, but would it be possible to get the old functionality through a warning-less 'date_guess_system_timezone'. The 'guess' in the function-name should be enough of a warning. People who opt-in to this behaviour explicitly comply to the possible inaccuracy of the result. I would be one of those people, and as much as it may disturb you; I feel I'm not alone. Evert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local time zone
hi, On Mon, Dec 12, 2011 at 2:30 PM, Evert Pot evert@filemobile.com wrote: The 'guess' in the function-name should be enough of a warning. People who opt-in to this behaviour explicitly comply to the possible inaccuracy of the result. I would be one of those people, and as much as it may disturb you; I feel I'm not alone. It is totally unreliable and has caused so many troubles (and consumed many of our debugging time). See this ML archive for the various discussions, or bugs.php.net. I do not think it is too much asking to an admin to setup the correct default timezone in php.ini on install, or to allow users to set it for their virtual hosts via the usual interface. In short, the amount of troubles on our side (support) is not worth it, in comparison to what it takes to have a sane setup. Cheers, -- 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
On Mon, 12 Dec 2011, Evert Pot wrote: On Dec 11, 2011, at 1:07 PM, Pierre Joye wrote: On Sun, Dec 11, 2011 at 1:59 AM, Oleg Oshmyan chor...@inbox.lv wrote: I am willing to work on patches but I suppose some consensus should be reached first. The consensus was that you have to set a valid default timezone in php.ini I feel there may be a lot of value for people being able to install PHP applications and run them without any additional configuration. What would be the recommended way to have PHP reflect the systems timezone? The best way is always going to be: set it up yourself. I like the PHP 5.4.0 behaviour of defaulting to UTC if it's not setup, but would it be possible to get the old functionality through a warning-less 'date_guess_system_timezone'. The 'guess' in the function-name should be enough of a warning. People who opt-in to this behaviour explicitly comply to the possible inaccuracy of the result. I would be one of those people, and as much as it may disturb you; I feel I'm not alone. The extension already has http://uk3.php.net/manual/en/function.timezone-name-from-abbr.php which is basically the guessing algorithm. 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
I do not think it is too much asking to an admin to setup the correct default timezone in php.ini on install, or to allow users to set it for their virtual hosts via the usual interface. We are not talking only about servers here. We are mainly talking about personal machines, including laptops of people who travel often. Of course it is possible to just say that whenever one changes the system time zone, one should also change the time zone in php.ini. But that becomes tedious, and if PHP's guessing algorithm works for some people, why not let them use it? It is totally unreliable and has caused so many troubles (and consumed many of our debugging time). I have proposed a couple of improvements, in particular one that could resolve some DST issues (using tzname to get two abbreviation hints). And by making it even more explicit that the algorithm performs but a guess, for example, by moving it to a function with 'guess' in the function name, bug reports of the sort 'the guess is wrong' can be given a very low priority if not closed right away. Finally, the unreliability of the guessing algorithm is exactly why I proposed using system-provided local time descriptions/APIs. This issue boils down to: people want software to behave the same way whichever language it is written in. Things written in Bourne shell, cmd.exe, C, Perl, Python, Ruby all use the system time zone, or at least that which was the system time zone when the program made its first call to a function like localtime. Even MySQL has a time zone called SYSTEM and uses it by default. PHP is the odd man out: not only does it not use the system time zone by default, as it instead tries to find one in its own time zone database that seems most similar, but it is also going to remove the only ready way to get any close to getting the system time zone in the next release. -- Oleg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local time zone
This might work on some distrbutions, but not nearly on all. And
definitely not on Windows. On Debian it's not a symlink for example.
It is still usable as one of the possibilities for the guessing algorithm
to examine.
Initially I also wanted to say that /usr/share/zoneinfo can be searched
if /etc/localinfo is not a symbolic link, but I have just run a test:
time { find /usr/share/zoneinfo -type f \
-exec cmp -s /etc/localtime '{}' \; -print; }
and it took 1.5 seconds on openSUSE 11.4 and a second on Mac OS X 10.6
(by the way, on the latter /etc/localtime is a symbolic link). I suppose
it would take less if I only examined paths corresponding to time zones
known to PHP but it would likely still take a long time. Thus this is
perhaps reasonable as optional behaviour (such as
date_system_timezone_guess($try_harder=false) called with true as the
argument) but certainly unwanted in code that executes by default.
It's a guess, and that's the problem. Guessing makes up for odd and
strange bugs if it's not 100% accurate (which it isn't).
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.
I can see why it is a bad idea to make such a time zone the default in a
language used mostly for server-side software, although replacing it with
a guess approximating such a time zone as the default, which is what PHP
5.1 did, seems even worse, and it is good to see that PHP 5.4 takes a
better approach. However, I do not see how this is a bad idea for scripts
people run among other software that all uses the system time zone--or
perhaps I should even say 'the system's notion of local time', since
(however uncommon this is) it might be different from any particular time
zone. I have searched in the archive of php-internals and not found any
discussion of this. Perhaps I am a bad searcher; I would appreciate if
you pointed me at some of the past discussion.
--
Oleg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Local time zone
hi, On Sun, Dec 11, 2011 at 1:59 AM, Oleg Oshmyan chor...@inbox.lv wrote: I am willing to work on patches but I suppose some consensus should be reached first. The consensus was that you have to set a valid default timezone in php.ini Cheers, -- 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
