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.
Projecting flattened dates out to both infinities is prohibitively wacky. Do I pick arbitrary maximum and minimum dates? Should I forgo premature projection, in lieu of on-demand processing? a combination of both?
Those are my leading choices atm.
calling ezic:load("/path/to/tzdata_folder") returns a list of records without erroring-out.
The content may not be accurate; @todo create accuracy tests (idea: use system's zic/localtime/tzselect/etc.).
