> Not UTC+1.0 because it's an integer. OTOH you are right about that on python 3 :-/

I apparently used python 3 to do the testing. (`int(…)` would be a good fix.)

However, timezones are a mess.  And it just so happens that some countries have [non-integer hour offsets](http://en.wikipedia.org/wiki/Nepal_Time) (hell, formerly there were countries that had [**seconds** offsets](http://pytz.sourceforge.net/#issues-limitations))  A better format we could use is `UTC±hh:mm` which is supported by dateutil, and also supports minutes and our Nepali friends (though not folks from the Netherlands living in the past — sorry, “history from the eyes of a person living it” bloggers):

```pycon
>>> dateutil.parser.parse('11:00:00 UTC+01:30')
datetime.datetime(2014, 3, 24, 11, 0, tzinfo=tzoffset(None, -5400))
```

> ISO 8601 has the problem of not being human editable.

Nikola is not used by humans, only by geeks — people likely who can do ISO 8601.  And really, do you think non-geeks have a problem until the timezone part?  year-month-day is understood by pretty much everyone, and some countries default to this.  Use a space as the separator, and everyone can do time: hh(0…24*):mm:ss is used by many people and understood by most of the world.  The only thing people might have problems with is the timezone offset, but — again — they can just ignore it (Nikola would assume `conf.TIMEZONE` if no offset specified); and most Nikola users know how to use the offset.

The people that might have problems are the `nikola webapp` folks that don’t work with our internals and that might be “your average Joe”, not a geek.  They can have a nice picker, problem solved.

\* ISO 8601 allows both 00:00 and 24:00 to refer to midnight, though 24:00 refers to tomorrow.  This is a catch, we might just go with RFC 3339 and drop support for `24:00`.