Question

I’ve read a bunch of posts on how flaky parsing time can be. I believe I have come up with a reliable way of converting an ISO8601-formatted timestamp here:

https://gist.github.com/3702066

The most important part being the astimezone(LOCALZONE) call when the date is parsed. This allowed time.mktime() to do the right thing and appears to handle daylight savings properly.

Are there obvious gotchas I’ve missed?

Answer 1

Your code does seem to work even for times that fall just before or just after daylight savings time transitions, but I am afraid it might still fail on those rare occasions when a location’s timezone offset actually changes. I don’t have an example to test with though.

So even if if does work (or almost always work), I think it’s crazy to convert a UTC time string to a UTC timestamp in a manner which involves or passed through local time in any way. The local time zone should be irrelevant. It’s an unwanted dependency. I’m not saying that you’re crazy. You’re just trying to work with the APIs you are given, and the C library’s time APIs are badly designed.

Luckily, Python provides an alternative to mktime() that is what the C library should have provided: calendar.timegm(). With this function, I can rewrite your function like this:

parsed = parse_date(timestamp)
timetuple = parsed.timetuple()
return calendar.timegm(timetuple)

Because local time is not involved, this also removes the dependency on pytz and the nagging doubt that an obscure artifact of somebody’s local timezone will cause an unwanted effect.