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
(probab
> > - 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
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 => ... )
> 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,1
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 2700B
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 preci
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 );
> >
> > pr
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 standar
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 fu
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
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 i
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::Sunris
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 lo
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
> 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::May
> > 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:
>
> > 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
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'
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?
>
> > > 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;
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_objec
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;
>
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.
Ho
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 "Pom
> 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
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] =
> 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
29 matches
Mail list logo
