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 `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.
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.
