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
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
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
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.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
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
hi Stas,
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...
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
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 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
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 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";
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:
-
using integer makes such features easier to implement (basic good
practice/programming 101) -
use strncmp to compare the format (yes, strncmp supports many characters)
-
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
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 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";
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:
- using integer makes such features easier to implement (basic good
practice/programming 101)- 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
On Mon, Oct 4, 2010 at 1:17 PM, Hannes Magnusson
hannes.magnusson@gmail.com 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
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...
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
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
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
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 (orgmdate())?
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
Stas Malyshev wrote:
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 (orgmdate())?
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