> (3) We cannot disable/remove ereg at compile time (today)
>
> I'm suggesting we alter (3) so that we, the people who compile
> PHP, can optionally remove this extension from our PHP 5.4+.
For what it's worth, I was able to successfully remove ereg from PHP 5.3
(.6, I think; this was a while ag
> public function \Customer getCustomer(){
> return $this->customer;
> }
>
> If the $customer instance variable is not declared with the type Customer
> then first of all IDE will not be able to spot an error, second compiler may
> have a slighly harder time of detecting a mismatch.
The compiler
> 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
> 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
> 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
> 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 /
> 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
>> 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.
>>
> Call for voting about the const array/string derefernce RFC now.
>
> you can find more info here:
> https://wiki.php.net/rfc/constdereference#vote
I have always wondered why array dereference does not just work on
arbitrary expressions in PHP like other operators do. Even with the
latest modifi
> 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
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 th
13 matches
Mail list logo
