Issue #7: Some Zones no longer observing DST are broen.
The matchspec generation function for universal time was wrong,
whereas it was fine for wall and local times. Fixing that line, and
considering the `current` flatzone time, was enough to get TZs like
Tokyo and Jamaica working correctly in tested cases.
Like in d98eed, errors are now returned as values rather than crashing
processes. This is a short-term solution for consistency, and can be
refactored to a saner model later.
add_offset was calculating DST differences wrong. It assumed to lose an hour, DST would be {-1,0,0}, in fact, DST went from {1,0,0} to {0,0,0}. add_offset now uses their differences (hence requires both as arguments)
normalize/2 was added to be able to set an arbitrary flag on a plain (i.e. native erlang datetime tuple) date. This is complicated by the fact that atoms "minimum", "max", etc. are still valid and need to fall through the normalization unaltered (for now).
ezic_zone:next/3 was not filtering the Zones to only those after UTCFrom. This may have caused an endless loop, always returning the earliest zone regardless of the progress of time. I wont know; I caught it rather early.
