Commit Graph

10 Commits

Author SHA1 Message Date
aj
9ad8f3c826 lots of work towards flattening the records. stalled at ezic_rule:next_event/4 2010-11-07 18:32:37 -08:00
aj
329f699e51 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.
2010-11-07 12:52:51 -08:00
aj
65ff337301 added stub of next_timechange method. 2010-11-06 17:13:15 -07:00
aj
d5cb707119 renamed the API methods, updated the README 2010-11-04 21:31:29 -07:00
aj
f4a48f09cf fixed bug with rule choice; dst was not being calculated correctly, Thanks Adelaide! 2010-11-04 04:28:23 -07:00
aj
7dd76519a0 happy path tested! current times correctly reported for LA, NY, Tokyo, and Jamaica!
Japan doesn't observer DST. I didn't know that.
2010-11-04 04:20:38 -07:00
aj
e9d247784e separated out rule and date logic. WIP: flattening the data, absolute from fuzzy dates, comparing dates 2010-11-03 23:33:06 -07:00
aj
3c965fe7b6 added debug build, fleshing out the tzdata parser. currently broken 2010-11-03 02:49:13 -07:00
aj
563f2c6e09 fleshed out API, and removed 'start method'. 2010-11-03 01:03:07 -07:00
aj
59f18e4270 added naive Makefile, stubs of modules, unit test coordinator (test_master) 2010-11-03 00:30:59 -07:00