On Tue, Oct 5, 2010 at 5:48 AM, Richard Lynch <c...@l-i-e.com> wrote: > On Sun, October 3, 2010 6:27 pm, Stas Malyshev wrote: >>> It looks like a sub optimal choice to have used string constants >>> instead of integer. However it could be still possible to define new >>> constants as numeric. It is then possible to do whatever needs to be >>> done as post or pre ops for the respective constants. >> >> I'm not sure what integers have to do with it? The constants define >> date >> formats that are in common use, RFC2616 is one of the commonest on the >> web and we don't have a constant for it... > > I'm not sure that using 1 for RFC822, 2 for RFC884, ... would have > been much better, really...
it is easily detectable and cannot be confused with a manually (by the user) defined format string. It is also fully BC, even when a format is updated. Format string requiring post/pre processing (like convert to GMT and then restore the TZ) can benefit from the easy detection without breaking BC. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
