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.

README.md

@@ -4,6 +4,18 @@ ezic is a set of erlang utilities for the Olsen timezone database files. See the
 
 
 
+Status
+------
+
+2010.11.07
+
+ * The time comparisons don't consider time relativity, so they're plain wrong. Within at least 24 hours of timechange or zone change, the results cannot be trusted.
+
+2010.11.04
+
+ * ezic is "apparently functional". It has been tested very lightly, a bit by unit tests, but mostly by inspection. It's probably not fit for production use.
+
+
 License
 -------
 
@@ -18,14 +30,6 @@ To maintain ezic's status as a public domain work, all contributions must also b
 
 
 
-Status
-------
-
-2010.11.04
-
- * ezic is "apparently functional". It has been tested very lightly, a bit by unit tests, but mostly by inspection. It's probably not fit for production use.
-
-
 API
 ---