Author belopolsky
Recipients ajaksu2, belopolsky, daniel.urban, l0nwlf, merwok, mihaic, poolie, r.david.murray, techtonik
Date 2012-06-19.02:46:49
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1340074012.91.0.11904093741.issue7584@psf.upfronthosting.co.za>
In-reply-to
Content
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 get RFC 3339 timestamp in local timezone instead of UTC.  This will be addressed in issue 9527.

2. If UTC timestamp is produced by a computer in non-UTC timezone, the offset should be specified as '-00:00'.  If this is important, an application can replace '+' with '-', but most likely specifying the correct local offset is a better option.

3. RFC 3339 requires support for leap seconds.  This limitation cannot be solved by adding a method to datetime.

Most importantly, given that there are several RFCs describing different  date formats, a datetime.rfcformat() method will be ambiguous.  (GNU date has --rfc-2822 and --rfc-3339 options and the later allows output of three different precisions.)

I am going to reject this RFE.  I don't think adding datetime.rfcformat() method will solve any real deficiency and whatever limitations datetime has with respect to producing RFC compliant timestamps should be addressed in future specific proposals.
History
Date User Action Args
2012-06-19 02:46:53belopolskysetrecipients: + belopolsky, techtonik, ajaksu2, merwok, r.david.murray, daniel.urban, l0nwlf, mihaic, poolie
2012-06-19 02:46:52belopolskysetmessageid: <1340074012.91.0.11904093741.issue7584@psf.upfronthosting.co.za>
2012-06-19 02:46:52belopolskylinkissue7584 messages
2012-06-19 02:46:49belopolskycreate