> 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
SystemTimeToTzSpecif
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
suppor
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
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 pr
> 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 P
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
> >
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.
>
> Ye
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 Identifi
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 di
On Tue, Dec 20, 2011 at 1:35 AM, David Muir 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
On 15/12/11 21:17, Pierre Joye wrote:
> On Wed, Dec 14, 2011 at 11:14 PM, Stas Malyshev
> 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,
On Wed, Dec 14, 2011 at 11:14 PM, Stas Malyshev 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
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 s
> 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
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 th
> 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, impleme
> 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 /
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 Malys
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.
is present in *nix, W
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.
is present in *ni
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 pa
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!
* 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
> 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= timezone>".
This is a good idea (or perhaps exactly the opposite, as I explained in my
previous ema
On Wed, Dec 14, 2011 at 11:26 AM, Derick Rethans 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 sl
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
>> 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.
>>
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
> 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
> 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 lapt
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 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
hi,
On Mon, Dec 12, 2011 at 2:30 PM, Evert Pot 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
> fe
On Dec 11, 2011, at 1:07 PM, Pierre Joye wrote:
> hi,
>
> On Sun, Dec 11, 2011 at 1:59 AM, Oleg Oshmyan 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 th
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,
hi,
On Sun, Dec 11, 2011 at 1:59 AM, Oleg Oshmyan 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.l
35 matches
Mail list logo
