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
post again as a top thread with this point being clarified please :)
On Wed, Dec 14, 2011 at 12:19 PM, Laruence wrote:
> On Tue, Dec 13, 2011 at 9:59 PM, Pierre Joye wrote:
>> On Tue, Dec 13, 2011 at 2:37 PM, Patrick ALLAERT
>> wrote:
>>> 2011/12/13 Nikita Popov :
This can't go into PHP 5
On Tue, Dec 13, 2011 at 9:59 PM, Pierre Joye wrote:
> On Tue, Dec 13, 2011 at 2:37 PM, Patrick ALLAERT
> wrote:
>> 2011/12/13 Nikita Popov :
>>> This can't go into PHP 5.4.0 in any case, because it is a feature
>>> addition and the release is already in RC.
>>
>> +1
>>
>> @Laruence
>> Can you re
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
16 matches
Mail list logo
