format date in RFC 3339 subset (profile) of ISO 8601

[anatoly techtonik <techtonik@…>]

Currently util.datefmt.format_datetime() is able to produce ISO 8601 compliant format given 'iso8601' as argument. The proposal is to increase interoperability by making datetime format compliant with RFC 3339 profile of ISO 8601.

That means that date will still be ISO 8601, but it will be additionally suitable for generating output that uses RFC 3339 based datetime, such as Atom.

See ​rfc:3339#section-5.6

trac/util/datefmt.py

@@ -100 +100 @@
     
     The formatting will be done using the given `format`, which consist
     of conventional `strftime` keys. In addition the format can be 'iso8601'
-    to specify the international date format.
+    to specify the international date format (compliant with rfc3339).
 
     `tzinfo` will default to the local timezone if left to `None`.
     """
@@ -125 +125 @@
     text = t.strftime(format)
     if normalize_Z:
         text = text.replace('+0000', 'Z')
+        text = text[:-2] + ":" + text[-2:]
     encoding = locale.getpreferredencoding() or sys.getdefaultencoding()
     if sys.platform != 'win32' or sys.version_info[:2] > (2, 3):
         encoding = locale.getlocale(locale.LC_TIME)[1] or encoding

[Christian Boos]

Why not, but please fix the patch (only do this substitution if test[-1] != 'Z').

[Christian Boos]

s/test/text/

[anatoly techtonik <techtonik@…>]

second edition

[anatoly techtonik <techtonik@…>]

Thanks for review. New version is attached. Will it be included in 0.11 series as well?

[Remy Blank]

I'll integrate this.

[Remy Blank]

Patch applied in [8708], along with a simplification of the logic in format_datetime().

[Martin Scharrer <martin@…>]

This doesn't work with my Trac installations (0.11.6 and 0.12dev). The colon is always missing. Trac itself apparently takes it as optional, but e.g. the Google Sitemap service rejects the generated dates as invalid because of the missing colon. This affects the ​th:GoogleSitemapPlugin.

Here the results of my manual test, the automatic tests look fine to me but apparently doesn't catch this.

Python 2.5.2 (r252:60911, Jan 20 2010, 23:14:04) 
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from trac.util.datefmt import format_datetime
>>> print format_datetime(0, 'iso8601')
1970-01-01T01:00:00+0100
>>> print format_datetime(0, 'iso8601 ')
1970-01-01T01:00:00+0100
>>> print format_datetime(0, 'iso8601 time')
01:00:00+0100

[Remy Blank]

Weird, this must be a locale issue. Here, I get the following:

Python 2.6.4 (r264, Mar  5 2010, 00:59:14)
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from trac.util.datefmt import format_datetime
>>> print format_datetime(0, 'iso8601')
1970-01-01T01:00:00+01:00
>>> print format_datetime(0, 'iso8601 ')
1970-01-01T01:00:00+01:00
>>> print format_datetime(0, 'iso8601 time')
01:00:00+01:00

What do you get for the following:

>>> from trac.util.datefmt import to_datetime, localtz
>>> to_datetime(0).astimezone(localtz).strftime('%Y-%m-%dT%H:%M:%S%z')
'1970-01-01T01:00:00+0100'
>>> localtz
<LocalTimezone "CET" 1:00:00 "CEST" 2:00:00>

Also, what's the output of "locale" on your system?

[Martin Scharrer <martin@…>]

Thanks for responding so quickly.

Here the requested output:

Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from trac.util.datefmt import to_datetime, localtz
>>> to_datetime(0).astimezone(localtz).strftime('%Y-%m-%dT%H:%M:%S%z')
'1970-01-01T00:00:00+0000'
>>> localtz
<LocalTimezone "GMT" 0:00:00 "IST" 1:00:00>
>>> 
>>> 

And my "locale":

LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=

[Martin Scharrer <martin@…>]

Sorry, the data above are from my home Trac 0.12 installation. This seems to work, I get the colon. My first post was from my workstation with Trac 0.11.6

On my server with Trac 0.11.6 I get the original missing colon and the follow output:

Python 2.5.2 (r252:60911, Jan 20 2010, 23:14:04) 
[GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from trac.util.datefmt import to_datetime, localtz
>>> to_datetime(0).astimezone(localtz).strftime('%Y-%m-%dT%H:%M:%S%z')
'1970-01-01T01:00:00+0100'
>>> localtz
<trac.util.datefmt.LocalTimezone object at 0x20075b90>

The locale settings are identical to my last post.

[Remy Blank]

Replying to Martin Scharrer <martin@…>:

Sorry, the data above are from my home Trac 0.12 installation. This seems to work, I get the colon. My first post was from my workstation with Trac 0.11.6

Heh, mid-air collision, and I was going to ask exactly that.

On my server with Trac 0.11.6 I get the original missing colon and the follow output:

Yes, this is to be expected, as this ticket has been fixed on trunk only. We don't have any plans to backport the fix to 0.11-stable, so I'm closing this again.

[Martin Scharrer <martin@…>]

Funny, I must have confused the versions then, because I actually checked if the above code was included in the Trac installations I used before reopening the ticket. I was under the (wrong) impression it had been backported.

Yeah, this happens if someone has three computer with three different tracs … Sorry for the noise!

[anatoly techtonik <techtonik@…>]

np. Datetime handling is a major Python weakness.