alerted to buginess in README. added notes & zic reference. removed local_to_utc conversion for now.

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.

src/ezic_rule.erl

@@ -2,7 +2,7 @@
 -include("include/ezic.hrl").
 
 
--export([current/2, relevant/2, sort/2]).
+-export([current/2, current_set/2, sort/2]).
 -export([from_time/1, dst_sec/1]).
 
 
@@ -10,9 +10,9 @@
 current(_, []) ->
     none;
 current(Now, Rules) ->
-    RelevantRules= lists:filter(fun(R)-> relevant(Now, R) end, Rules),
-%    ?debug("RelevantRules: ~p", [RelevantRules]),
-    SRules= lists:sort(fun sort/2, RelevantRules),
+    Current_SetRules= lists:filter(fun(R)-> current_set(Now, R) end, Rules),
+%    ?debug("Current_SetRules: ~p", [Current_SetRules]),
+    SRules= lists:sort(fun sort/2, Current_SetRules),
     CRule= choose_rule(SRules),
     CRule.
 
@@ -27,15 +27,15 @@ sort(R1, R2) ->
 
 
 
-relevant(Now, Rule=#rule{from=F, to=T}) ->
+current_set(Now, Rule=#rule{from=F, to=T}) ->
     {{Y,_,_},_} = Now,
     case ezic_date:date_between(Y, {F,T}) of
 	false -> false;
-	true -> relevant2(Now, Rule)
+	true -> current_set2(Now, Rule)
     end.
 
 
-relevant2(Now, #rule{in=Month, on=Day, at=Time}) ->
+current_set2(Now, #rule{in=Month, on=Day, at=Time}) ->
     {{Y,_,_},_} = Now,
     RTime= {{Y, Month, Day}, Time},
     ezic_date:compare_datetimes(RTime, Now).