[patch] Implement timezone-formats in date-formatting

[sune.kirkeby@…]

In db/typecast timezone-information from the database is discarded. This is bad, which this patch fixes.
Also, the timezone-related formatting characters were NotImplemented in utils/dateformat, this patch also fixes that.
(I assigned this to database-wrapper, but it's just as much template-system...)

[sune.kirkeby@…]

Fix timesince to take timezones into account

[sune.kirkeby@…]

Patch with changes from both the other patch and bugfixes

[sune.kirkeby@…]

Bugfix update of previous patch

[Sune Kirkeby <sune.kirkeby@…>]

The timezone-parsing patch is bad. Very bad. It breaks the unittests for all but PostgreSQL, and datetime comparisons break spectacularly because datetime is brain-dead when it comes to timezones (​Unsafe datetime comparisons).

I worked out a much better way of getting what I want (timezone-formatting in dateformat); in dateformat I
assume that the timezone is local, unless explicitly given. This works beautifully.

Also, I implemented all formats except "Swatch internet time", implemented backslash-escaping of format-chars
and added unittests.

[Sune Kirkeby <sune.kirkeby@…>]

New, improved and working patch for timezone-formatting in dateformat

[Adrian Holovaty]

Sune -- Just to be clear, which patches are currently valid? Just the last two (timezone.2.patch and dateformat.patch)? Apply those two, and that's it?

[Sune Kirkeby <sune.kirkeby@…>]

Nope, just dateformat.patch, apply that and all should be good :)

[Sune Kirkeby <sune.kirkeby@…>]

Except,

+        t = time.mktime(now)

in timesince should be

+        t = now.timetuple()

Sorry.

[Adrian Holovaty]

I get the following unit-test errors after applying this patch (and renaming the variable from my_birthday to sunes_birthday).

'dateformat' module: API test failed
====================================
Code: "format(sunes_birthday, 'O')"
Line: 21
Expected: "'+0100'\n"
Got: "'+1800'\n"

'dateformat' module: API test failed
====================================
Code: "format(sunes_birthday, 'r')"
Line: 25
Expected: "'Sat, 7 Jul 1979 22:00:00 +0100'\n"
Got: "'Sat, 7 Jul 1979 22:00:00 +1800'\n"

'dateformat' module: API test failed
====================================
Code: "format(sunes_birthday, 'U')"
Line: 37
Expected: "'300445200'\n"
Got: "'304117200'\n"

'dateformat' module: API test failed
====================================
Code: "format(sunes_birthday, 'Z')"
Line: 49
Expected: "'3600'\n"
Got: "'64800'\n"

'dateformat' module: API test failed
====================================
Code: "format(summertime, 'O')"
Line: 54
Expected: "'+0200'\n"
Got: "'+1900'\n"

'dateformat' module: API test failed
====================================
Code: "format(wintertime, 'O')"
Line: 58
Expected: "'+0100'\n"
Got: "'+1800'\n"

[Adrian Holovaty]

In [969]: Lightly refactored django.utils.dateformat to make it use less code. Also integrated some of Sune's improvements from the #479 patch, including support for backslash escaping. Also vastly improved template docs for the {% now %} tag

[Sune Kirkeby <sune.kirkeby@…>]

django.utils.dateformat should be reloaded after the timezone-fidgeting in the test-module,
since the UTC-offsets are calculated when dateformat is first imported. D'oh!

I'll attach a new test-module now.

/me hopes this works

[Adrian Holovaty]

I get the exact same unit-test errors now...Any ideas?

[Adrian Holovaty]

Also, your original patch had changes to core/db/typecasts.py...Those should probably still be applied, no?

[Sune Kirkeby <sune.kirkeby@…>]

Also, your original patch had changes to core/db/typecasts.py...Those should probably still be applied, no?

I'd rather not; I learned that having timezones come back from the database is going to break a lot of client code; because datetime barfs if you try mixing timezone-aware and timezone-naive datetimes. And, as long as the database returns datetimes in settings.TIME_ZONE (which I know postgresql does) the defaulting to LocalTimezone in dateformat and timesince is going to do the right thing; even accounting for DST.

[Sune Kirkeby <sune.kirkeby@…>]

I get the exact same unit-test errors now...Any ideas?

This time I actually tried running the tests with env TZ=America/Chicago, which gave me the same errors you see. And, it seems a reload of tzinfo is not enough for some reason, so I removed the pre-calculation of timezone-offsets in tzinfo, which does the trick for me. I'll attach the new django.utils.tzinfo.

And the reload-trick in the latest dateformat-tests is not needed with this tzinfo.

[Adrian Holovaty]

(In [992]) Fixed #479 -- Implemented time-zone formats in dateformat. Thanks, Sune