On Wed, Sep 5, 2012 at 4:14 AM, Lester Caine <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. > > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - > http://lsces.co.uk/wiki/?page=**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<http://rainbowdigitalmedia.co.uk> > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
