Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
status: pending - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7584
___
Alexander Belopolsky alexander.belopol...@gmail.com 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:
anatoly techtonik techto...@gmail.com added the comment:
On Wed, Jul 14, 2010 at 1:52 AM, Alexander Belopolsky
rep...@bugs.python.org 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
anatoly techtonik techto...@gmail.com added the comment:
I must add - many times better than no solution at all.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7584
___
Alexander Belopolsky alexander.belopol...@gmail.com 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,
R. David Murray rdmur...@bitdance.com 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.
--
Martin Pool m...@sourcefrog.net added the comment:
Z is well established as meaning UTC time
http://en.wikipedia.org/wiki/Coordinated_Universal_Time#Time_zones 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
Changes by Mihai Capotă mi...@mihaic.ro:
--
nosy: +mihaic
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7584
___
___
Python-bugs-list mailing list
Alexander Belopolsky belopol...@users.sourceforge.net 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
anatoly techtonik techto...@gmail.com 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
anatoly techtonik techto...@gmail.com 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
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Sat, Jun 5, 2010 at 11:35 AM, anatoly techtonik
rep...@bugs.python.org wrote:
..
s/datetime/date\/time/ in the last sentence, as the complication comes from:
-- start offtopic --
1. the vast amount of various date
anatoly techtonik techto...@gmail.com added the comment:
On Sat, Jun 5, 2010 at 7:00 PM, Alexander Belopolsky
rep...@bugs.python.org wrote:
On Sat, Jun 5, 2010 at 11:35 AM, anatoly techtonik
rep...@bugs.python.org wrote:
..
s/datetime/date\/time/ in the last sentence, as the complication
Alexander Belopolsky belopol...@users.sourceforge.net 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()
R. David Murray rdmur...@bitdance.com 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
R. David Murray rdmur...@bitdance.com 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
anatoly techtonik techto...@gmail.com 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.
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
assignee: - belopolsky
nosy: +belopolsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7584
___
anatoly techtonik techto...@gmail.com 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
R. David Murray rdmur...@bitdance.com 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
Daniel Urban urban.dani...@gmail.com 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
anatoly techtonik techto...@gmail.com 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 rep...@bugs.python.org
Daniel Urban urban.dani...@gmail.com 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
Daniel Urban urban.dani...@gmail.com 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
Daniel Urban urban.dani...@gmail.com added the comment:
Is anyone still interested in this? Is there a problem with my patch?
Thanks.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7584
anatoly techtonik techto...@gmail.com 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
Daniel Urban urban.dani...@gmail.com 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
anatoly techtonik techto...@gmail.com 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
anatoly techtonik techto...@gmail.com 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
Daniel Urban urban.dani...@gmail.com 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:
anatoly techtonik techto...@gmail.com added the comment:
Atom spec -
http://www.atomenabled.org/developers/syndication/atom-format-spec.php#date.constructs
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7584
Daniel Diniz aja...@gmail.com 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
Éric Araujo mer...@netwok.org 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
Éric Araujo mer...@netwok.org added the comment:
Should have checked before speaking. RFC 3339 is a subset of W3CDTF, as said on
Daniel’s first link.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7584
New submission from anatoly techtonik techto...@gmail.com:
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
35 matches
Mail list logo
