ml>> this is likely due to the fact that JAM stores the
 ml>> dates in unix format... that is, the number of
 ml>> seconds since the epoch... yes, this is the format
 ml>> that runs out of positive numbers in 2038 ;)

 SH>   31 more years of computing! ;)  Then we're really screwed.

haha, yep... unless someone comes up with a way of fixing things... i've
thought about the (theoreticaly) simple task of changing the epoch as we
reach the "end"... the calendar starts over every X years and
exactly overlays a "template" that is X years long... there is a
rhythm to it that i'm not able to pick up from my 1986 Reader's Digest
Almanac but there is a pattern in the charts... unfortunately the charts go
from 1776 to 2014 and i think the pattern is bigger than that...

but, actually, it may be easier than i'm looking at... it could be that the
pattern is twofold... twofold in that the regular years cycle thru in their
rhythm and the leapyears have their own rhythm...

it seems easy enough... i've got 7 normal year charts and 7 leapyear
charts... i've already looked at the 68 year cycle and 136 year cycles and
they get tossed out of sync on a leapyear each time... i know the pattern
is in there and it is just a matter of time to locate it and then figure
out how to apply it ;)

)\/(ark