PHP is used for server-side software that needs to use the remote
client's time zone and for distributed software potentially running on
geographically dispersed servers that needs to use a common time zone,
and in these cases there is no doubt that the time zone should be
manually specified and that the default should be universally constant if
it exists at all. However, PHP is also used for utilities that people run
on their personal machines, and in most cases they want to use the
current system time zone, whatever it is. PHP 5.3 provides a way
to at least guess the current system time zone:
date_default_timezone_set(@date_default_timezone_get());
PHP 5.4, as currently planned, removes this ability and does not add any
other way to get the system time zone. First, let me ask: is this right
or does another way exist? Second, if no other way exists, I urge that
the guessing algorithm is added back in or split out into a separate
function, say, date_system_timezone_get. Third, I propose improvements
to the guessing algorithm on UNIX:
-
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. -
/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 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.
I am willing to work on patches but I suppose some consensus should be
reached first.
--
Oleg
hi,
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
hi,
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
hi,
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
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
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.iniI 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
- 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
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
<snip>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:
We will not be adding code that has to scan the filesystem.
<snip>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.
Perhaps I am a bad searcher; I would appreciate if you pointed me at
some of the past discussion.
http://marc.info/?t=119988823700001&r=1&w=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
<snip>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.
Perhaps I am a bad searcher; I would appreciate if you pointed me at
some of the past discussion.http://marc.info/?t=119988823700001&r=1&w=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
<snip>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.
Perhaps I am a bad searcher; I would appreciate if you pointed me at
some of the past discussion.http://marc.info/?t=119988823700001&r=1&w=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
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
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
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
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.
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. InWhich 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
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
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
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
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
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 UTCSigh...
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
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
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
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
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
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.
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.
<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
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
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.
<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
<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 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.
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
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
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
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
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
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
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