Jean Forget schreef:
Will your module contain the names of the days? Like 'Brocoli' (12
Pluviose) or 'Pomme de terre' (22 Vendemiaire)?
My module will support brocoli for 12 Pluvi?se, but I am not so
sure about Pomme de terre. My source (Agenda r?publicain 197)
tells me that Pomme de terre
13.0.0.0.0 == 0.0.0.0.0 . Except that 0 isn't used on the baktun level,
so that it stays 13 until 13.19.19.17.19. The day after that is
1.0.0.0.0.
Date::Maya uses:
$results [0] %= $max_baktun;
$results [0] = $max_baktun if $results [0] == 0;
I guess thats safes for RD values before the
I don't know what you mean by 'RD values'.
Rata Die
That's my interpretation of what the calendar FAQ writes about Mayan
calendars. I'm not an expert on Mayan calendars, about all I know
of it, I got from the calendar FAQ.
Unfortunately the CC book doesn't cover this at all. I might try to
On Wed, 2 Apr 2003, Joshua Hoblitt wrote:
- should it have a clone method?
Only if it has methods that can change the internal object state after
it's created, like DateTime.pm's set(), set_time_zone(), etc.
- when from_object is used should the value for seconds returned by utc_rd_values be
Joshua Hoblitt schreef:
- when from_object is used should the value for seconds returned by
utc_rd_values be stored then returned by the object itself? This
would allow chaining of calendars without a loss of precision.
Best would probably be te either use Mayan time (if it is known
(probably
- what other methods would be useful?
Offhand, -set(), -add(), -subtract(), accessors for each component
(baktun, katun, etc.)
-set_baktun or -set( baktun = ... ) ? Should DT::Duration objects be
supported?
Why does from_object take a language parameter? Cut and paste-o? It's
not being
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
Joshua Hoblitt schreef:
This would also solve the following problem:
$d = DateTime-new( year = 2003, month = 4, day= 3,
hour = 0,minute = 0, second = 0 );
$md = DateTime::Calendar::Mayan-from_object( object = $d );
print $md-date, \n; #
Joshua Hoblitt schreef:
Wrong answer #2:
print DateTime::Calendar::Mayan-from_object(
object = DateTime-now(time_zone = 'Europe/Amsterdam') );
So you are proposing something like this?
print DateTime::Calendar::Mayan-now( timezone = 'Europe/Amsterdam' )-date;
Either
On Thu, 3 Apr 2003, Joshua Hoblitt wrote:
Actually, I'm starting to think that it might be better instead to simply
have a local_rd_values method and use that instead, maybe.
Or barf on floating times.
Or document it.
In practice, I think _most_ people working with multiple calendar
2) If you want to use the Mayan calendar *now*, as a replacement for the
Gregorian calendar, you also need a time system. And 'our' system is the
only sensible candidate. (Unless the Mayan time system is known?)
You lost me on the you also need a time system. Why?
If you want to
Wrong answer #2:
print DateTime::Calendar::Mayan-from_object(
object = DateTime-now(time_zone = 'Europe/Amsterdam') );
So you are proposing something like this?
print DateTime::Calendar::Mayan-now( timezone = 'Europe/Amsterdam' )-date;
Either that, or your
On Thu, 3 Apr 2003, Eugene van der Pijll wrote:
And this works. But even more people will use DateTime-now. And then
a floating time would be wrong.
Why would a floating time be wrong then?
As an example, the first program I wrote using
DateTime::Calendar::Mayan.
use DateTime;
my
Dave Rolsky schreef:
On Thu, 3 Apr 2003, Eugene van der Pijll wrote:
And this works. But even more people will use DateTime-now. And then
a floating time would be wrong.
Why would a floating time be wrong then?
(I think I meant to say 'a utc time', as now() returns a 'utc' time.
However,
14 matches
Mail list logo
