Hi!
On one side there's a clear BC break which, according to the related RFC, is to be considered as a blocker, on the other one, a strong and valid argument regarding spreading additional server variables. I'm not sure being late in the release process is truely a valid argument for accepting a BC break.
If we are to fix it, I don't think it's too late. One of the purposes of the RC process is to find out stuff like this - i.e. BC breaks - and fix them before the release. I do not see a big risk in adding new SERVER variable - I don't believe there's any code that relies on certain variable *not* existing, and since the code to produce it already exists and considered stable, there's very little risk in just renaming it.
Can't we make some compromise here like making all date/time classes/functions work uniformly with ints and floats?
However for this is probably way too late, since it's not a BC fix, it's completely new and untested functionality.
So if somebody wants to make a patch that makes REQUEST_TIME be back as it was and make REQUEST_TIME_MSEC (or something like this) have msec precision - I think it would be fine. Doing anything to "all date/time classes/functions" is definitely out of the question, IMO. For 5.4.1, it may be considered if done in a clean manner, but not for 5.4.0.
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
