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
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
On Tue, Dec 13, 2011 at 9:59 PM, Pierre Joye pierre@gmail.com wrote:
On Tue, Dec 13, 2011 at 2:37 PM, Patrick ALLAERT patrickalla...@php.net
wrote:
2011/12/13 Nikita Popov nikita@googlemail.com:
This can't go into PHP 5.4.0 in any case, because it is a feature
addition and the
post again as a top thread with this point being clarified please :)
On Wed, Dec 14, 2011 at 12:19 PM, Laruence larue...@php.net wrote:
On Tue, Dec 13, 2011 at 9:59 PM, Pierre Joye pierre@gmail.com wrote:
On Tue, Dec 13, 2011 at 2:37 PM, Patrick ALLAERT patrickalla...@php.net
wrote:
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
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
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!
*
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
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
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
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
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
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,
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
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
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
16 matches
Mail list logo
