Commit Graph

22 Commits

Author SHA1 Message Date
aj heller
ca64849fed fixes #7; adds many tests for #7; cleans up ezic_flatten debug messages
Issue #7: Some Zones no longer observing DST are broen.

The matchspec generation function for universal time was wrong,
whereas it was fine for wall and local times. Fixing that line, and
considering the `current` flatzone time, was enough to get TZs like
Tokyo and Jamaica working correctly in tested cases.
2012-12-17 23:55:37 -08:00
aj heller
52ad0119cb removes unused code and changes variable names for clarity 2012-12-17 15:22:59 -08:00
lsowen
e535590013 working implementation of mnesia and ets based ezic. 2012-12-05 15:14:21 -05:00
lsowen
2866c9c505 I think I solved the deadlock of nested gen_server:call()s 2012-12-05 13:17:20 -05:00
lsowen
4f3364a76d Much cleaner, but not working, because I have a circular loop 2012-12-04 21:36:44 -05:00
lsowen
9d0df77b29 Now using named ets tables.
More closely mirrors the design of the mnesia backed version.
2012-11-07 14:06:27 -05:00
lsowen
e8385d7d86 move forward on the transition to ets over mnesia 2012-11-02 22:50:17 -04:00
aj
a90d6246ec moving from mnesia to ets. matchspecs are complicated when dates and atoms are involved. 2010-11-18 00:28:50 -08:00
aj
22395e2f47 max_year base case bug fixed. ezic:localtime/1 works.
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.
2010-11-14 00:27:44 -08:00
aj
d664384c60 Costa Rica's flatzones aren't processed after 1992. Gotta check her out. 2010-11-13 22:54:44 -08:00
aj
3f438e66e0 handled case where zone and rule both end. dealing with Tripoli recursion bug (ambiguous year in ezic_date:for_rule) 2010-11-13 03:25:50 -08:00
aj
a7b0adcbce repaired ezic_date:add_offset. able to normalize plain dates. notes and tests
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).
2010-11-12 03:07:15 -08:00
aj
3e77287db6 there is a subtle bug in wall-time calculations. Asia/Irkutsk times are incorrect. 2010-11-12 01:22:50 -08:00
aj
e042ad5ea9 updated some comments to be more accurate, more descriptive 2010-11-12 00:05:57 -08:00
aj
1340f64d8b semantic api change: flatten_zones -> flatten_all_zones. 2010-11-11 23:54:38 -08:00
aj
c976e63349 removed all warnings. fixed bug in ezic_zone:next/3. unit tests for ezic_zone:next/3
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.
2010-11-11 23:52:10 -08:00
aj
1520c631ef roughed-in the "nested" rule processing (flatten). hurdle on rule years->max. 2010-11-10 13:01:03 -08:00
aj
e48e793a36 flattening algorithm needs to be reworked.
also, datetime methods aren't consistent in their naming and return values.
2010-11-10 03:18:57 -08:00
aj
d84a0c1822 datetime manipulation is now much clearer. tests were added, and expectations stated explicitly in many places. rules got lots of attention. 2010-11-10 01:52:13 -08:00
aj
216a8d9ff8 brainstorming the flattening algorithm, slight API change 2010-11-09 23:32:25 -08:00
aj
d00937c3e9 lots of gutting. purposes, input, and output were unclear in many places. still broken. 2010-11-08 01:29:15 -08:00
aj
9ad8f3c826 lots of work towards flattening the records. stalled at ezic_rule:next_event/4 2010-11-07 18:32:37 -08:00