Note that it often makes sense to handle naive datetimes (such as user input) in local times. In such cases, round-tripping a timezone-aware datetime through PyYAML — for example, dumping/loading fixtures in Django — will result in data corruption.

Change History

I started looking at what it would take to create a patch for this and I've come up on a few hard problems.

The first thing I did was go ahead and patch construct_yaml_timestamp so that if a + or -HH:MM timezone was specified, a tzinfo instance was created with that offset, much like was suggested in this ticket's description.

When I went to add UTC support for Z timezones, I started looking more critically at the implementation of the spec itself http://yaml.org/type/timestamp.html. Specifically, according to my reading, any timestamp that does not have a timezone—even those with no time specified at all—should be UTC. Thus, because you can't localize a date instance, and because date instances don't appear to make any assertions as to time-of-day in contrast to the spec which says missing time should be read as 00:00:00Z, construct_yaml_timestamp should never return a date instance for a date-only timestamp value, but instead a datetime with hour 0, minute 0, and tzinfo UTC.

I do fear that such changes will break a lot of code that are used to receiving either date instances or naïve datetime instances, though.

My current work on this problem as a starting point for discussion: http://nopaste.info/1b9398393d.html Keep in mind it does break tests right now, largely because date and datetime instances are incomparable as well as naïve and offset-aware datetime instances.