Will Fitch wrote:
Hi, Lester - I'll update the patch and RFC to include this format.  This is the
format I'll use unless others have a better approach:

2012-09-01T00:00:00-0500 (America/Chicago)

Just working through another backlog of 'todo' items.

Your current RFC includes -0500 in the examples, but that is purely due to your own setup. This is the real problem here since you can't take a date/time string and clone a new object. You have to define a DateTimeZone object prior to creating the DateTime object. You have 'America/Chicago' set as your default timezone, and that is fine for your local working, but part of Derick's objection is that how this all hangs together is always a two stage process.

Now if you can make the above string clone a matching DateTime/DateTimeZone object pair, then part of the objection would go, but *I* would still object to any default here since it's just as likely you want to leave the timezone off and handle it separately as include it in an output string.

Also it is worth noting that DateTime::__construct specifically ignores the $timezone parameter when the date string includes an offset! This may well be considered a bug and perhaps $timezone parameter should take priority, but it's all these little things that get missed when one 'just fills in a missing function' ... someone just taking the default string and trying to create a new date object for a different timezone might get caught out, so that particular point should be included in any documentation. Actually currently the returned string would not work anyway?

The RFC is 'needs more work' but I still feel that adding this 'shortcut' will create more problems than it will provide any benefit.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to