On Mon, 26 Dec 2011, Patrick ALLAERT wrote: > 2011/12/24 Pierre Joye <pierre....@gmail.com>: > > > > Right but there is a clear BC break here. And yes I really don't like > > how datetime deals with that but it is how it is, and it is certainly > > the only case where it fails (or almost). > > > > On Sat, Dec 24, 2011 at 4:18 PM, Ilia Alshanetsky <i...@ilia.ws> wrote: > >> Introducing additional server > >> variables just makes things inconsistent, especially this late in the > >> release cycle. > > On one side there's a clear BC break which, according to the related > RFC, is to be considered as a blocker,
An RFC? Which one? > 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. > Can't we make some compromise here like making all date/time > classes/functions work uniformly with ints and floats? It's parsing a *string*, not an int or float. Changing anything with how the parser works is definitely going to be a clear BC break. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
