Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
> 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 contact the authors for some clarification. > It's good to realize that all three Mayan calendars (does > DateTime::Calendar::Maya cover all three?) are, unlike the Gregorian It will include all three shortly. I just wanted to get some early feed back. > calendar, cyclic. Also, while the long count (that's the Mayan calendar > being discussed, the others are the Haab and the Tzolkin) cycles after 13 > baktuns, the Mayans had larger units. 20 baktuns make a pictun, 20 pictuns > make a calabtun, 20 calabtuns make a kinchiltun, and 20 of those make > a alautun. One alautun is 2304000 days, or more than 63 million years. Theres a little note in the POD that says these larger units maybe supported in the future. I'm considering addition and subtract of the larger units. Mostly for fun as I don't think it would be very useful. Cheers, -J --
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
On Fri, Apr 04, 2003 at 11:28:49AM -1000, Joshua Hoblitt wrote: > > 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 Mayan epoch. I don't know what you mean by 'RD values'. > I just want some confirmation that this is the right way to do things. 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. It's good to realize that all three Mayan calendars (does DateTime::Calendar::Maya cover all three?) are, unlike the Gregorian calendar, cyclic. Also, while the long count (that's the Mayan calendar being discussed, the others are the Haab and the Tzolkin) cycles after 13 baktuns, the Mayans had larger units. 20 baktuns make a pictun, 20 pictuns make a calabtun, 20 calabtuns make a kinchiltun, and 20 of those make a alautun. One alautun is 2304000 days, or more than 63 million years. Abigail
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
> 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 Mayan epoch. I just want some confirmation that this is the right way to do things. Cheers, -J
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
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" is 11 Vend?miaire and > 22 Vend?miaire is "p?che". What are your sources? You're right, it's the 11th. My mistake. Eugene
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
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, when converting it to other calendars, utc and floating work
identically.)
now() doesn't always return today's (local) date. If you want that, you
need the time_zone. Calendars that are tz aware, also show the correct
(local) date. Calendars that do not know about time and time zones, show
the utc date.
> > As an example, the first program I wrote using
> > DateTime::Calendar::Mayan.
> >
> > use DateTime;
> > my $d = DateTime->now;
> > $d->set_time_zone( 'Europe/Amsterdam' );
> > $d->set_time_zone( 'floating' );
> > print $d->strftime("%A %d %B %Y\n");
>
> Can you show the output and explain the problems? Honestly, I have no
> clue what this _should_ print.
It shows the correct output, because of the workaround (two calls to
set_time_zone). If you remove the second one (to 'floating'), you'll see
that the output of the last two calendars can be inconsistent with the
output of the first two.
(Try an offset of '+1200' or '-1200' in the first call to time_zone, and
compare with the always correct ouput in timezone 'utc' to see the
problem more clearly. At this moment:
UTC: it's Thursday 03 April 2003
Thursday 21 March 2003 Julian
Jeudi 12 Clinamen 130 [St Georges Dazet, poulpe au regard de soie]
12,19,10,2,10
+1200: it's Friday 04 April 2003
Friday 22 March 2003 Julian
Jeudi 12 Clinamen 130 [St Georges Dazet, poulpe au regard de soie]
12,19,10,2,10
The first two are correct. The last two do not implement times, and are
wrong.)
Apologies for the unclearness. But it's already late, here in +0200.
Eugene
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
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 $d = DateTime->now;
> $d->set_time_zone( 'Europe/Amsterdam' );
> $d->set_time_zone( 'floating' );
> print $d->strftime("%A %d %B %Y\n");
>
> use DateTime::Calendar::Julian;
> $d = DateTime::Calendar::Julian->from_object( object => $d );
> print $d->strftime("%A %d %B %Y Julian\n");
>
> use DateTime::Calendar::Pataphysical;
> $d = DateTime::Calendar::Pataphysical->from_object( object => $d );
> print ucfirst $d->strftime("%A %d %B %Y [%*]\n");
>
> use DateTime::Calendar::Mayan;
> $d = DateTime::Calendar::Mayan->from_object( object => $d );
> print $d->date, "\n";
Can you show the output and explain the problems? Honestly, I have no
clue what this _should_ print.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
Dave Rolsky schreef:
> In practice, I think _most_ people working with multiple calendar systems
> will not even care about the time component, and will be doing stuff like:
>
> my $date = DateTime->new( year => 1900, month => 7, day => 6 );
>
> my $mayan = DateTime::Calendar::Mayan->from_object( object => $date );
(etc.)
And this works. But even more people will use DateTime->now. And then
a floating time would be wrong.
As an example, the first program I wrote using
DateTime::Calendar::Mayan.
use DateTime;
my $d = DateTime->now;
$d->set_time_zone( 'Europe/Amsterdam' );
$d->set_time_zone( 'floating' );
print $d->strftime("%A %d %B %Y\n");
use DateTime::Calendar::Julian;
$d = DateTime::Calendar::Julian->from_object( object => $d );
print $d->strftime("%A %d %B %Y Julian\n");
use DateTime::Calendar::Pataphysical;
$d = DateTime::Calendar::Pataphysical->from_object( object => $d );
print ucfirst $d->strftime("%A %d %B %Y [%*]\n");
use DateTime::Calendar::Mayan;
$d = DateTime::Calendar::Mayan->from_object( object => $d );
print $d->date, "\n";
Eugene
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
> > > 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 module should convert from the _local_ rd values, > instead of the _utc_ values. (Dave's proposal) I have the feeling that this could lead to strange errors when chaining calendars together. I'd rather see floating time become equivalent to UTC. > That would make Wrong answer #2 work; I'd settle for that. > > It would mean changing the rules, of course. As you said, the behaviour > is "correct" as it is; I'd keep it this way until a better solution is > available. Agreed. :) -J --
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
> > > 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 replace DateTime with DateTime::Calendar::Mayan, you want > to have at least comparable functionality. If you want your server logs, > or your diary, or your system clock, to show Mayan dates, you also want > to include a time. > > Perhaps I should have said: "If I want to use the Mayan calendar > *now*, as a replacement for the Gregorian calendar, I also want a time > system."? > > (I accept that it would be _wrong_ to include a time. But that doesn't > mean it isn't right!) So write a DateTime::Time as an abstract base class for all the calendars that don't have a time system. :) I don't think it's worth getting into a holy war about messing with calendar X. I think it's reasonable to go to the pragmatic route and say a lot of people would like to have HMS support in most of the DT:Calendars. -J --
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
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 systems will not even care about the time component, and will be doing stuff like: my $date = DateTime->new( year => 1900, month => 7, day => 6 ); my $mayan = DateTime::Calendar::Mayan->from_object( object => $date ); # display mayan date $mayan->add( baktuns => 2 ); my $new_date = DateTime->from_object( object => $mayan ); # display Gregorian date In this case, since floating has the same utc_rd_values as local_rd_values, everything works just fine. > > I think trying to impose modern time systems on ancient calendar is not > > very feasible. > > So the million dollar question is should DT::C::Mayan support timezones? > Or is UTC the right thing to do? I'd say supporting time zones in other calendars is probably not worth the effort, even if we could agree on what "correct" support would look like ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
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 that, or your module should convert from the _local_ rd values, instead of the _utc_ values. (Dave's proposal) That would make Wrong answer #2 work; I'd settle for that. It would mean changing the rules, of course. As you said, the behaviour is "correct" as it is; I'd keep it this way until a better solution is available. Eugene
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
> > Best would probably be te either use Mayan time (if it is known > > (probably not)), or to implement 'our' time (complete with timezones > > etc.). > > 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. > I think trying to impose modern time systems on ancient calendar is not > very feasible. So the million dollar question is should DT::C::Mayan support timezones? Or is UTC the right thing to do? -J --
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
> > I was thinking that there might be some Mayan glyphs in UTF8. :) > > I couldn't find them. It was just an idea as I was cutting and pasting the language stuff. > BTW, I wonder if I may use UTF-8 math symbols in the "sets" POD. > > Some links I've got: > - shows how to use the mayan glyphs: > http://www.halfmoon.org/names.html Good link. Thanks > - The whole utf8 standard: > http://www.unicode.org/unicode/uni2book/u2.html -J --
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
> Wrong answer #1: > print DateTime::Calendar::Mayan->now->date; > > This prints the Mayan date corresponding to the UTC date, which can be > different from the local date. (Which can't be helped, as the local > timezone isn't mentioned.) > > Wrong answer #2: > print DateTime::Calendar::Mayan->from_object( > object => DateTime->now(time_zone => 'Europe/Amsterdam') ); > > (assuming that now() accepts a timezone. if it doesn't, replace the > DateTime object by DateTime->now->set_time_zone( 'Europe/Amsterdam' )) > > Because DT::C::Mayan converts from UTC, and does not keep the timezone > info, this has the same result as answer #1. > > Correct answer: > print DateTime::Calendar::Mayan->from_object( > object => DateTime->now(time_zone => 'Europe/Amsterdam')-> > set_time_zone => 'floating' )); So you are proposing something like this? print DateTime::Calendar::Mayan->now( timezone => 'Europe/Amsterdam' )->date; > Look at all the websites saying the world will end in 2012. They are > based on the Mayan calendar, which reaches it's "new year" (13.0.0.0.0) > in December 2012. Ok - I'll add this. -J --
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
Abigail schreef: > On Thu, Apr 03, 2003 at 10:46:10PM +0200, Eugene van der Pijll wrote: > > > > 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 replace DateTime with DateTime::Calendar::Mayan, you want to have at least comparable functionality. If you want your server logs, or your diary, or your system clock, to show Mayan dates, you also want to include a time. Perhaps I should have said: "If I want to use the Mayan calendar *now*, as a replacement for the Gregorian calendar, I also want a time system."? (I accept that it would be _wrong_ to include a time. But that doesn't mean it isn't right!) Eugene
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
On Thu, Apr 03, 2003 at 10:46:10PM +0200, Eugene van der Pijll wrote: > > 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? Abigail
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
Eugene van der Pijll wrote: > One of the things I would like to see is a DateTime::TimeZone::Local > module. > my $tz_utr = DateTime::TimeZone::Local( longitude => +5.1 ); > .. or even ... > my $tz_utr = DateTime::TimeZone::LocalRealSun( longitude => +5.1 ); That's DateTime::Event::Sunrise, isn't it? - Flavio S. Glock
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
Abigail schreef: > > Best would probably be te either use Mayan time (if it is known > > (probably not)), or to implement 'our' time (complete with timezones > > etc.). > > The latter, IMO, doesn't make any sense. "our" time certainly wasn't > used by the Mayans. There are a number of arguments in favour of using 'our' time: 1) The Mayan calendar (or at least, parts of it) is still used in Guatemala and Mexico. I'm not sure, but I think they use our time system too. 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?) 3) If time zones are not implemented, it's hard to convert DateTime objects into Mayan dates (and back). See my previous mail to Joshua for an example. > Furthermore, in the Maya era, "we" didn't even use > "our" time. We were using some form of solar time, and that could be > quite off from the time that was used 30 km further. One of the things I would like to see is a DateTime::TimeZone::Local module. my $tz_utr = DateTime::TimeZone::Local( longitude => +5.1 ); .. or even ... my $tz_utr = DateTime::TimeZone::LocalRealSun( longitude => +5.1 ); > I haven't had an interest in porting my Date::Maya module to DateTime > because mixing in some non-Mayan time concept (as opposed to dates) is, > IMO, just plain wrong. Yes, that is one good argument against using 'our' time. Eugene
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
On Thu, 3 Apr 2003, Eugene van der Pijll wrote: > Best would probably be te either use Mayan time (if it is known > (probably not)), or to implement 'our' time (complete with timezones > etc.). 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. I think trying to impose modern time systems on ancient calendar is not very feasible. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
On Thu, 3 Apr 2003, Abigail wrote: > The latter, IMO, doesn't make any sense. "our" time certainly wasn't > used by the Mayans. Furthermore, in the Maya era, "we" didn't even use > "our" time. We were using some form of solar time, and that could be > quite off from the time that was used 30 km further. I agree. > I haven't had an interest in porting my Date::Maya module to DateTime > because mixing in some non-Mayan time concept (as opposed to dates) is, > IMO, just plain wrong. WTF? I'm not sure exactly where you came up with the idea that this is being encouraged. Your own module converts from Mayan calendar to Julian days. Julian days can be easily converted to Gregorian dates. So how is this different from what the DateTime::Calendar modules allow? It's not. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
Joshua Hoblitt wrote: > I was thinking that there might be some Mayan glyphs in UTF8. :) I couldn't find them. BTW, I wonder if I may use UTF-8 math symbols in the "sets" POD. Some links I've got: - shows how to use the mayan glyphs: http://www.halfmoon.org/names.html - The whole utf8 standard: http://www.unicode.org/unicode/uni2book/u2.html - Flavio S. Glock
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
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"; # prints 12,19,10,2,10 > > > > $d = DateTime->new( year => 2003, month => 4, day => 3, > > hour => 0,minute => 0, second => 0, > > time_zone => 'Europe/Amsterdam' ); > > $md = DateTime::Calendar::Mayan->from_object( object => $d ); > > > > print $md->date, "\n"; # prints 12,19,10,2,9 > > I think thats correct behavior isn't it? The value for RD utc passed > will be different because the top example is a floating time. It's correct behaviour, for some values of correct. But it is unexpected that 2003-04-03 is converted into 12,19,10,2,9, only because of the timezone. An even worse example: how do you print today's date? Wrong answer #1: print DateTime::Calendar::Mayan->now->date; This prints the Mayan date corresponding to the UTC date, which can be different from the local date. (Which can't be helped, as the local timezone isn't mentioned.) Wrong answer #2: print DateTime::Calendar::Mayan->from_object( object => DateTime->now(time_zone => 'Europe/Amsterdam') ); (assuming that now() accepts a timezone. if it doesn't, replace the DateTime object by DateTime->now->set_time_zone( 'Europe/Amsterdam' )) Because DT::C::Mayan converts from UTC, and does not keep the timezone info, this has the same result as answer #1. Correct answer: print DateTime::Calendar::Mayan->from_object( object => DateTime->now(time_zone => 'Europe/Amsterdam')-> set_time_zone => 'floating' )); > 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? Look at all the websites saying the world will end in 2012. They are based on the Mayan calendar, which reaches it's "new year" (13.0.0.0.0) in December 2012. Or look at the calendar FAQ, as Abigail said. (The link can be found on http://datetime.perl.org .) Eugene
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
On Thu, Apr 03, 2003 at 09:31:16PM +0200, Eugene van der Pijll wrote: > 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 not)), or to implement 'our' time (complete with timezones > etc.). The latter, IMO, doesn't make any sense. "our" time certainly wasn't used by the Mayans. Furthermore, in the Maya era, "we" didn't even use "our" time. We were using some form of solar time, and that could be quite off from the time that was used 30 km further. I haven't had an interest in porting my Date::Maya module to DateTime because mixing in some non-Mayan time concept (as opposed to dates) is, IMO, just plain wrong. Abigail
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
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: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
> 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"; # prints 12,19,10,2,10 > > $d = DateTime->new( year => 2003, month => 4, day => 3, > hour => 0,minute => 0, second => 0, > time_zone => 'Europe/Amsterdam' ); > $md = DateTime::Calendar::Mayan->from_object( object => $d ); > > print $md->date, "\n"; # prints 12,19,10,2,9 I think thats correct behavior isn't it? The value for RD utc passed will be different because the top example is a floating time. > 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? > You use a comma as default separator for the long count. On the web, > I've only found periods. That was a goof, it'll be fixed. Cheers, -J --
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
On Thu, 3 Apr 2003, Joshua Hoblitt wrote: > > > - 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 I think ->set( baktun => ... ). And no, there's no need to support DT::Duration objects. > > Why does from_object take a language parameter? Cut and paste-o? It's > > not being used internally. > > I was thinking that there might be some Mayan glyphs in UTF8. :) Ok. That's fine with me, but then you really need to put the language param in new() > > Also, according to Abigail's Data::Maya module, there are three possible > > Mayan epochs. Maybe this should be changeable on a per-object basis. > > I haven't looked at her module (but I will now that I know it exists). > The epoch is already separated out for easy changes. I was thinking of > a ->set_epoch() that can select from built-ins or accept an epoch in rd. Actually, Abigail is a he. Don't ask me. ->set_epoch sounds good, but you'll also need an "epoch" param to the constructor(s). -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
> > - 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 used internally. I was thinking that there might be some Mayan glyphs in UTF8. :) > Also, according to Abigail's Data::Maya module, there are three possible > Mayan epochs. Maybe this should be changeable on a per-object basis. I haven't looked at her module (but I will now that I know it exists). The epoch is already separated out for easy changes. I was thinking of a ->set_epoch() that can select from built-ins or accept an epoch in rd. Cheers, -J --
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
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 not)), or to implement 'our' time (complete with timezones etc.). The last option can be done very easily by including the line: use DateTime::Time; (as soon as I have written that module, of course...) 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"; # prints 12,19,10,2,10 $d = DateTime->new( year => 2003, month => 4, day => 3, hour => 0,minute => 0, second => 0, time_zone => 'Europe/Amsterdam' ); $md = DateTime::Calendar::Mayan->from_object( object => $d ); print $md->date, "\n"; # prints 12,19,10,2,9 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. You use a comma as default separator for the long count. On the web, I've only found periods. Eugene
Re: [ANNOUNCE]([kinda) DateTime::Calendar::Mayan
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 > stored then returned by the object itself? This would allow chaining of calendars > without a loss of precision. Yes, please do so. I will add this to the calendar development docs. > - what other methods would be useful? Offhand, ->set(), ->add(), ->subtract(), accessors for each component (baktun, katun, etc.) > - can I have some suggestions for tests? The tests you have so far look fine. As you add more methods, add more tests ;) Why does from_object take a language parameter? Cut and paste-o? It's not being used internally. Also, according to Abigail's Data::Maya module, there are three possible Mayan epochs. Maybe this should be changeable on a per-object basis. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
