Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan

2003-04-03 Thread Abigail
On Thu, Apr 03, 2003 at 10:11:24AM -1000, Joshua Hoblitt wrote:
 
  Some other things I noticed:
 
  Baktun's are numbered 13, 1, 2, 3, ..., 12 (and repeat). Yours are
  numbered -inf, ..., -2, -1, 0, 1, 2, ..., +inf, so the module will only
  give the correct long count from about 2700BC to about 2400AD. You may
  want to add a 'cycle' count (1 cycle = 13 baktuns). Also, the default
  value for baktun should perhaps be 13.
 
 The easiest thing to do would be to catch that stuff in the constructor.  However I 
 had assumed that a baktun could be 0-20 as 1 pictun = 20 baktun.  Do you have source 
 of documentation you could point me at?


The calendar FAQ.


Abigail


Re: Grand Unified Theory of Date/Time modules

2003-02-02 Thread abigail
On Tue, Jan 28, 2003 at 02:37:31PM +1100, Rick Measham wrote:
 
 There are two time periods that do not change: Years (time the earth takes
 to travel around the sun) and Days (time the earth take to spin one complete
 revolution).

But they do change. If the length of a day was constant, we would not
have leap seconds. However, we do. Also, the time it takes for the
earth to travel around the sun isn't constant, but that's irrelevant.
The years used in calenders used by humans typically count an integer
number of days, and not the irrational number of days it takes for the
earth to travel around the sun. I'm pretty sure 2004 won't have the same
length as 2003.



Abigail



Re: DateTime Namespace

2003-01-13 Thread Abigail
On Sun, Jan 12, 2003 at 08:08:17PM -0500, Matthew Simon Cavalletto wrote:
 
 Does it invite others to add their own modules? Pushing the main 
 implementation down a level might seem like a meaningless detail, but 
 my hope is that it helps to signal to other module authors that they're 
 not going to be second-class citizens.


What I would like to see is what the benefit for the various modules
and authors is to adhere to this new API/Time::Piece object. From what
I've seen so far, it looks like something heavily Gregorian biased,
with lots of methods.

I'm the author of Date::Maya, which just do two things, translate from
Julian days to Mayan dates, and from Mayan dates to Julian days. As the
discussion goes about the API/Time::Piece object, I just wonder why I
should bother. Gregorian years, month or weeks just don't make any sense.
And if you want to do something like 'find the date 100 days later', you
just translate the date to julian days, add 100, and translate it back.

I'm not against a common API/object, but only if both the API and object
are small and simple. Things like (Gregorian) years, months and date,
and its handling of it, belong, IMO, in a subclass, and not the base class.



Abigail