Will Fitch wrote:
On Wed, Sep 5, 2012 at 4:14 AM, Lester Caine <les...@lsces.co.uk <mailto:les...@lsces.co.uk>> wrote: 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 DaTime 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 format being suggested (ISO8601 + TZ name) won't work without addressing the concern you mentioned as well as correctly parsing the TZ name. The RFC is 'needs more work' but I still feel that adding this 'shortcut' will create more problems than it will provide any benefit. I'm currently working on revamping the RFC and offering up two separate solutions. You are right that it's going to be difficult to please everyone, but I do want a solution that can be acceptable to most. If that ends up being no solution at all, so be it. I do believe through enough conversation and potentially adjusting DateTime's current behavior (e.g. the TZ point you brought up), a solution can be reached. It's important to keep one of Derick's points in mind as well - https://wiki.php.net/rfc/datetime_and_daylight_saving_time.
That is actually part of the reason all my internal processing is only ever UTC. so I only use the timezone to display data so does not affect you on that side. However I know that there is a black hole if someone does try and enter a date and time in that 1 hour missing window :)
-- 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
