[issue7584] datetime.rfcformat() for Date and Time on the Internet

Changes by Alexander Belopolsky : -- status: pending -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue7584] datetime.rfcformat() for Date and Time on the Internet

Alexander Belopolsky added the comment: I have reviewed RFC 3339 and it looks like the following produces a fully compliant timestamp: >>> print(datetime(2000,1,1, tzinfo=timezone.utc).isoformat('T')) 2000-01-01T00:00:00+00:00 I see the following remaining issues: 1. It is often desired to

[issue7584] datetime.rfcformat() for Date and Time on the Internet

anatoly techtonik added the comment: I must add - many times better than no solution at all. -- ___ Python tracker ___ ___ Python-bugs

[issue7584] datetime.rfcformat() for Date and Time on the Internet

anatoly techtonik added the comment: On Wed, Jul 14, 2010 at 1:52 AM, Alexander Belopolsky wrote: > I am still -1 on adding specialized formatting methods to the datetime class. >  I think this should be done in specialized modules. No problem - add "formats" module and I'll be happy. >On th

[issue7584] datetime.rfcformat() for Date and Time on the Internet

R. David Murray added the comment: email.utils.format_datetime implements RFC 5322 date format, which is very different from RFC 3339. I don't remember enough about what I read in RFC 3339 to answer your question about isoformat. -- ___ Python tra

[issue7584] datetime.rfcformat() for Date and Time on the Internet

Alexander Belopolsky added the comment: David, Isn't the requested feature now implemented as email.utils.format_datetime()? Also, what is the difference between RFC 3339 format and the one provided by datetime.isoformat? >>> print(datetime(2000,1,1, tzinfo=timezone.utc).isoformat('T')) 200

[issue7584] datetime.rfcformat() for Date and Time on the Internet

Martin Pool added the comment: Z is well established as meaning "UTC time" so shouldn't be used for "zone not known." rfc 3393 is clear that it's equivalent to +00:00. So the questions seem to be: * should there be an i

[issue7584] datetime.rfcformat() for Date and Time on the Internet

Changes by Mihai Capotă : -- nosy: +mihaic ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue7584] datetime.rfcformat() for Date and Time on the Internet

Alexander Belopolsky added the comment: Adding issue 7989 as a dependency because having pure python implementation in the CPython tree will make it much easier to experiment with new datetime features. I am still -1 on adding specialized formatting methods to the datetime class. I think th

[issue7584] datetime.rfcformat() for Date and Time on the Internet

anatoly techtonik added the comment: On Sat, Jun 5, 2010 at 7:00 PM, Alexander Belopolsky wrote: > On Sat, Jun 5, 2010 at 11:35 AM, anatoly techtonik > wrote: > .. >> s/datetime/date\/time/ in the last sentence, as the complication comes  from: >> -- start offtopic -- >> 1. the vast amount of

[issue7584] datetime.rfcformat() for Date and Time on the Internet

Alexander Belopolsky added the comment: On Sat, Jun 5, 2010 at 11:35 AM, anatoly techtonik wrote: .. > s/datetime/date\/time/ in the last sentence, as the complication comes  from: > -- start offtopic -- > 1. the vast amount of various date and time modules/functions "Vast" is a bit of oversta

[issue7584] datetime.rfcformat() for Date and Time on the Internet

anatoly techtonik added the comment: s/datetime/date\/time/ in the last sentence, as the complication comes from: -- start offtopic -- 1. the vast amount of various date and time modules/functions 2. the little amount of what they can do I still hardly believe that there is no way to get curre

[issue7584] datetime.rfcformat() for Date and Time on the Internet

anatoly techtonik added the comment: > According to my reading of RFC 3339, it is not correct to produce 'Z' > timestamps when local offset is not known. It is not said that 'Z' SHOULD NOT be produced if local offset is unknown. Even if offset is unknown, UTC still can be the preferred referen

[issue7584] datetime.rfcformat() for Date and Time on the Internet

R. David Murray added the comment: I see I didn't think it through far enough. Given this, it seems that the Atom standard is saying, "if you don't know your actual UTC offset, you can't generate a valid ATOM timestamp". Which sorta makes sense, though you'd think they'd want to accept a -00

[issue7584] datetime.rfcformat() for Date and Time on the Internet

Alexander Belopolsky added the comment: > It seems to me that we should not try to produce an RFC 3339 compliant > date string from a naive datetime. It will be practical to accept > that restriction once issue 5094 is resolved. Does this mean that t.rfcformat() should fail if t is naive? Acc

[issue7584] datetime.rfcformat() for Date and Time on the Internet

R. David Murray added the comment: I just took a look at RFC 3339, and I see what you mean, Anatoly, about the meaning of -00:00. But reading further: "While the Internet does have a tradition of accepting reality when creating specifications, this should not be done at the expense of int

[issue7584] datetime.rfcformat() for Date and Time on the Internet

anatoly techtonik added the comment: 1. David, as an original reporter who needed this for Trac (http://trac.edgewall.org/ticket/8662) and couple of other projects I strongly for 'Z' ending by default, unless you are going to explain the full difference in documentation. Expect to answer the

[issue7584] datetime.rfcformat() for Date and Time on the Internet

Changes by Alexander Belopolsky : -- assignee: -> belopolsky nosy: +belopolsky ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue7584] datetime.rfcformat() for Date and Time on the Internet

Daniel Urban added the comment: Here is a new patch. The name of the optional argument is "default_utcoffset" which is obviously too long, but I can't think a better name. Any suggestions? (I think simply "utcoffset" would be misleading, because the value of the argument is only used for nai

[issue7584] datetime.rfcformat() for Date and Time on the Internet

R. David Murray added the comment: I think Daniel's suggestion of having an option to control this is the best way to handle the different use cases. And I think the default should be -00:00, as he suggested. Removing 2.7 and 3.1 since 3.2 is the only branch open to new features at this poi

[issue7584] datetime.rfcformat() for Date and Time on the Internet

anatoly techtonik added the comment: Let's quote RFC 3339: """ 4.3. Unknown Local Offset Convention If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00". This differs semantically from an offset of "Z" or "+00:00", wh

[issue7584] datetime.rfcformat() for Date and Time on the Internet

Daniel Urban added the comment: > The point is that your implementation doesn't allow people to generate > 'Z'-ending timestamp if they need a subset of rfc3339. That is exactly right. Do you have any suggestion, how to do that? Maybe an optional argument to the rfcformat method? Something lik

[issue7584] datetime.rfcformat() for Date and Time on the Internet

anatoly techtonik added the comment: The point is that your implementation doesn't allow people to generate 'Z'-ending timestamp if they need a subset of rfc3339. -- ___ Python tracker

[issue7584] datetime.rfcformat() for Date and Time on the Internet

Daniel Urban added the comment: > I do not think that -00:00 or +00:00 will be invalid Atom timestamp, > but to implement parser of rfc3339 timestamp, Z handling is still > needed. I can easily imagine people making wrong assumption that > parsing 00:00 at the end would be enough for proper roun

[issue7584] datetime.rfcformat() for Date and Time on the Internet

anatoly techtonik added the comment: I do not think that -00:00 or +00:00 will be invalid Atom timestamp, but to implement parser of rfc3339 timestamp, Z handling is still needed. I can easily imagine people making wrong assumption that parsing 00:00 at the end would be enough for proper roun

[issue7584] datetime.rfcformat() for Date and Time on the Internet

anatoly techtonik added the comment: > It also says that if "the offset to local time is unknown, this can > be > represented with an offset of "-00:00"". So I don't think we can write > "Z" or "+00:00" if we don't know the UTC offset. >> but Atom >> specification mentions that > It says "an

[issue7584] datetime.rfcformat() for Date and Time on the Internet

Daniel Urban added the comment: > My Python code as well as your patch doesn't specify that "Z" must be > present when time zone offset is unknown or absent, Yes, that is because RFC 3339 explicitly says (in 4.3.) that -00:00 is "differs semantically from an offset of "Z" or "+00:00", which im

[issue7584] datetime.rfcformat() for Date and Time on the Internet

anatoly techtonik added the comment: Thanks Daniel. I am still interested in this. My Python code as well as your patch doesn't specify that "Z" must be present when time zone offset is unknown or absent, but Atom specification mentions that and I believe this is that most users expect to see

[issue7584] datetime.rfcformat() for Date and Time on the Internet

Daniel Urban added the comment: Is anyone still interested in this? Is there a problem with my patch? Thanks. -- ___ Python tracker ___ __

[issue7584] datetime.rfcformat() for Date and Time on the Internet

Daniel Urban added the comment: I've made a patch. This patch adds a datetime_rfcformat function to datetimemodule.c which is available from Python as the datetime.rfcformat method in the datetime module. This method returns the date in RFC 3339 format: -MM-DDTHH:MM:SS[.mm]+HH:MM.

[issue7584] datetime.rfcformat() for Date and Time on the Internet

anatoly techtonik added the comment: Atom spec - http://www.atomenabled.org/developers/syndication/atom-format-spec.php#date.constructs -- ___ Python tracker ___ ___

[issue7584] datetime.rfcformat() for Date and Time on the Internet

Éric Araujo added the comment: Should have checked before speaking. RFC 3339 is a subset of W3CDTF, as said on Daniel’s first link. -- ___ Python tracker ___ ___

[issue7584] datetime.rfcformat() for Date and Time on the Internet

Éric Araujo added the comment: Note that the Atom format requires a subset of RFC 3339 (which is in turn a subset of ISO 8601 if I remember correctly, and is the same as the W3C Datetime Format): https://www.tools.ietf.org/html/rfc4287#section-3.3 Summary: Atom requires using an uppercase T b

[issue7584] datetime.rfcformat() for Date and Time on the Internet

Daniel Diniz added the comment: It looks like feed generators need this feature[1]. See also issue 5207 and a current implementation[2]. [1] http://validator.w3.org/feed/docs/error/InvalidRFC3339Date.html [2] http://code.google.com/p/formattime/ -- keywords: +easy nosy: +ajaksu2 prior

[issue7584] datetime.rfcformat() for Date and Time on the Internet

New submission from anatoly techtonik : RFC 3339 defines a standard for Date and Time on the Internet. http://www.ietf.org/rfc/rfc3339.txt Given that Python is increasingly popular on the Internet is should include convenience function to generate RFC 3339 timestamps in standard library. It i