# rfc2616 datetime format? - Thread: https://externals.io/message/49840 - Original archive: https://news-web.php.net/php.internals/49840 - Started by Stas Malyshev on 2010-10-02T01:18:23+00:00 - Messages: 15 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #49840 — Stas Malyshev — 2010-10-02T01:18:23+00:00 URL: https://externals.io/message/49840#49840 Hi! Any reason why DateTime doesn't have a constant for RFC2616 (HTTP) date format? RFC1123 and 'r' are _almost_ there but 2616 explicitly states TZ must be "GMT" and 1123 format produces +0000 instead. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #49844 — Richard Lynch — 2010-10-03T11:38:36+00:00 URL: https://externals.io/message/49840#49844 · In reply to: #49840 > Any reason why DateTime doesn't have a constant for RFC2616 (HTTP) > date > format? RFC1123 and 'r' are _almost_ there but 2616 explicitly states > TZ > must be "GMT" and 1123 format produces +0000 instead. If you'd find it useful, I don't see any reason not to add it... There are an awful lot of RFC date formats, I guess, and I suppose it could be overwhelming eventually, but they seem innocuous enough to just add as needed. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE --- ## #49853 — Derick Rethans — 2010-10-03T18:32:21+00:00 URL: https://externals.io/message/49840#49853 · In reply to: #49840 > Any reason why DateTime doesn't have a constant for RFC2616 (HTTP) date > format? RFC1123 and 'r' are _almost_ there but 2616 explicitly states TZ must > be "GMT" and 1123 format produces +0000 instead. The reason is that in order to format a DateTime object as GMT, it needs to be converted to GMT... and you can't simply do that with just a constant consisting of a string of format characters. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #49854 — Pierre Joye — 2010-10-03T18:50:32+00:00 URL: https://externals.io/message/49840#49854 · In reply to: #49853 hi, > > > > […] > > The reason is that in order to format a DateTime object as GMT, it needs > to be converted to GMT... and you can't simply do that with just a > constant consisting of a string of format characters. 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. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #49856 — Stas Malyshev — 2010-10-03T23:25:49+00:00 URL: https://externals.io/message/49840#49856 · In reply to: #49853 Hi! > The reason is that in order to format a DateTime object as GMT, it needs > to be converted to GMT... and you can't simply do that with just a > constant consisting of a string of format characters. I see what you mean and it makes sense, having constant may imply that you can use it with any date and get proper result... But RFC2616 is the one of the most used formats on the Web - actually, the format that is called COOKIE is not the one that should be used in cookies - RFC2616 should be used instead. COOKIE one uses T, which may or may not be GMT, depending on the date and local system settings. Maybe we should have proper RFC format too, accompanied with appropriate warning that you should use it with GMT dates (or `gmdate()`)? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #49857 — Stas Malyshev — 2010-10-03T23:27:13+00:00 URL: https://externals.io/message/49840#49857 · In reply to: #49854 Hi! > 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... -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #49859 — Pierre Joye — 2010-10-04T02:14:02+00:00 URL: https://externals.io/message/49840#49859 · In reply to: #49857 hi Stas, > Hi! > > > […] > > 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 mean in ext/date and as a reply to Derick, not your request which is totally valid. A date time object has the timezone information. If the constants were integers, it would be very straightforward to do some operations before calling the formatting functions depending on a given predefined format. It should still be possible to do it by testing the string contents (strncmp), but that's not very clean. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #49860 — Derick Rethans — 2010-10-04T08:42:15+00:00 URL: https://externals.io/message/49840#49860 · In reply to: #49859 > > > […] > > I mean in ext/date and as a reply to Derick, not your request which is > totally valid. A date time object has the timezone information. If the > constants were integers, it would be very straightforward to do some > operations before calling the formatting functions depending on a > given predefined format. It should still be possible to do it by > testing the string contents (strncmp), but that's not very clean. Stop talking about something you don't know anything about, please. Those constants are not *one* format letter, they are many. Maybe you could have tried this: echo DateTime::RFC822, "\n"; Derick --- ## #49861 — Derick Rethans — 2010-10-04T08:55:08+00:00 URL: https://externals.io/message/49840#49861 · In reply to: #49856 > > […] > > I see what you mean and it makes sense, having constant may imply that > you can use it with any date and get proper result... But RFC2616 is > the one of the most used formats on the Web - actually, the format > that is called COOKIE is not the one that should be used in cookies - > RFC2616 should be used instead. COOKIE one uses T, which may or may > not be GMT, depending on the date and local system settings. Maybe we > should have proper RFC format too, accompanied with appropriate > warning that you should use it with GMT dates (or `gmdate()`)? Well, `gmdate()` is only part of it; the same constants are also used for the DateTime object (which is preferred over timestamps anyway). The problem lays exactly there because we can't just convert the timezone of an object just for formatting. I wanted to prevent adding just a format letter for the whole format as well (which would partially solve it), but we're almost out of letters. Adding a format letter that forces GMT means we would need to loop over the whole format string twice, making things highly more complicated. It is a tricky one, and let's think about whether we can come up with something useful here. cheers, Derick --- ## #49862 — Pierre Joye — 2010-10-04T09:29:00+00:00 URL: https://externals.io/message/49840#49862 · In reply to: #49860 > > > > […] > > Stop talking about something you don't know anything about, please. > Those constants are not *one* format letter, they are many. Maybe you > could have tried this: > > echo DateTime::RFC822, "\n"; Maybe you could read what I wrote instead of replying in such stupid manner, that could lead the discussions in a constructive direction, thanks. Key parts were: 1. using integer makes such features easier to implement (basic good practice/programming 101) 2. use strncmp to compare the format (yes, strncmp supports many characters) 2. is bad as it has the side effects of applying to a format given manually even if one did not intend to use it this way, it could have BC issues but I'm not sure at all if such format exists. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #49863 — Hannes Magnusson — 2010-10-04T11:17:59+00:00 URL: https://externals.io/message/49840#49863 · In reply to: #49862 > > > […] > > Maybe you could read what I wrote instead of replying in such stupid > manner, that could lead the discussions in a constructive direction, > thanks. > > Key parts were: > > 1. using integer makes such features easier to implement (basic good > practice/programming 101) > 2. use strncmp to compare the format (yes, strncmp supports many characters) Are you proposing that the constants become integers? so, DATE_RFC_1234 will be equal to "1234"? And then date(DATE_RFC_1234); will print out formatted string? I am afraid that would break craploads of applications, and become very confusing. -Hannes --- ## #49864 — Pierre Joye — 2010-10-04T11:20:06+00:00 URL: https://externals.io/message/49840#49864 · In reply to: #49863 On Mon, Oct 4, 2010 at 1:17 PM, Hannes Magnusson wrote: > I am afraid that would break craploads of applications, and become > very confusing. That's why I said "BC" earlier. But it could work for new formats. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #49869 — Richard Lynch — 2010-10-05T03:48:30+00:00 URL: https://externals.io/message/49840#49869 · In reply to: #49857 > > […] > > 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... You'd still have to look up the string format, and this GMT one would still be an oddball requiring pre-processing to convert to GMT, as I understand it. Perhaps a whole new "pool" of constants for `gmdate()` formatting??? GMT_RFC_2616, for example??? There are probably others in the same boat, yes? Let the record show that I am painfully aware of my ignorance relative to Derick with regards to Date Time matters. :-) -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE --- ## #49870 — Pierre Joye — 2010-10-05T06:51:47+00:00 URL: https://externals.io/message/49840#49870 · In reply to: #49869 > > > […] > > 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 --- ## #49871 — Lester Caine — 2010-10-05T07:34:07+00:00 URL: https://externals.io/message/49840#49871 · In reply to: #49856 Stas Malyshev wrote: > > […] > > I see what you mean and it makes sense, having constant may imply that > you can use it with any date and get proper result... But RFC2616 is the > one of the most used formats on the Web - actually, the format that is > called COOKIE is not the one that should be used in cookies - RFC2616 > should be used instead. COOKIE one uses T, which may or may not be GMT, > depending on the date and local system settings. Maybe we should have > proper RFC format too, accompanied with appropriate warning that you > should use it with GMT dates (or `gmdate()`)? There are a number of competing requirements from dates, relating to the core problem of not ACTUALLY having a usable flag from remote users as to their actual time zone ( DST information not supplied by browser ;) ). So the only thing that can be guaranteed is a GMT date/time, and it is that which I now use in the database for ALL stored timestamps. Displaying that information as a 'local' time is rather hit and miss depending on how you identify 'local', so timezone while being bundled into the 'date', is a totally independent element and often while the offset NOW may be right, displaying GMT time for an earlier 'stamp' may be an hour wrong if the user DST can not be identified? If your application is using date/times that are not gmt based, then you have to then manage the problem of comparing times which may have an hour difference on the day following a DST change. but most sites seem to assume that the server local time is an acceptable base, which then DOES cause a problem when supplying time information to remote users? SO while the 'format' of the printout is well documented, converting the supplied data is a separate problem? -- 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// Firebird - http://www.firebirdsql.org/index.php