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.
The db crash happens when calling `ezic_db:get_all(X)` when `X` is not
a valid table name. `ezic_db_ets` crashes, causing the `ezic_db`
server to crash, tossing the database with it. The solution prevents
ezic_db_ets:get_all/1 from crashing, and instead returns an error
value.
The simplification here eliminated some code through
deduplication. The `handle_call` functions could be improved
similarly.
The `ezic_db` server would crash on a bad lookup (no_zone,
ambiguous_zone, etc.). The old error notification method for bad
lookups (crashing) was killing the server and apparently eliminating
the in-memory tables.
in the case of ambiguous timezones, an "ambiguous_zone" error is thrown with the two valid zones.
if no zones existed for the given local time (i.e. DST eliminated the hour in question), a "no_zone" error is thrown.
otherwise, the date is returned
the final flatzone for every Zone should end at "current" for every *_to time. This is inaccurate, but accuracy is only guaranteed up to ?MAX_YEAR (=2500 by default).
that working, I fleshed out the few methods required to get ezic:utc_to_localtime/2 working, thus localtime/1 working. I've only tested localtime/1 at this point.
additionally, mnesia appears to have its data corrupted every time I stop and start a node. I've got to read up on working with mnesia; it's not behaving as I would expect.
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.
Time comparisons are patently wrong. They do not consider s/w/u/g/z time modifiers, so the comparisons can be off by hours. At least 24 hours within any time or zone change, ezic will give unreliable results.
I think a solution can involve "flattening" the data, starting from the earliest time possible for each zone/rule, going forward.
There exist ambiguous local times for zones and rules. For example, on Nov 7th, in Los Angeles, the times from 1:00:00am to 1:59:59am were repeated, once for PDT and once for PST. Given a local time in that zone between those times, we cannot determine what UTC time is unambiguously. Similar for Zone transitions where fall-back occurs.
