RE: DateTime::Calendar::Julian doc bug

2003-02-27 Thread Peter J. Acklam
Rick Measham <[EMAIL PROTECTED]> writes: > > Better: > sub mfloor($) { >return 0 unless $_[0]*1 != 0; >return int($_[0]) if (($_[0] >= 0) || (int($_[0]) == $_[0])); >return int($_[0]) -1; > } sub floor { my $x = $_[0]; my $ix = int $x; $ix <= $x ? $ix : $ix

Re: DateTime::Calendar::Julian doc bug

2003-02-27 Thread Rick Measham
On 28/2/03 4:38 pm, Rick Measham at [EMAIL PROTECTED] spake thus: > sub floor($) { >return 0 unless $_[0]*1 == $_[0]; # This might not be the best way :) >return int($_[0]) if $_[0] >= 0; >return int($_[0]) -1; > } Better: sub mfloor($) { return 0 unless $_[0]*1 != 0; return i

Re: DateTime::Calendar::Julian doc bug

2003-02-27 Thread Rick Measham
On 28/2/03 4:59 pm, Dave Rolsky at [EMAIL PROTECTED] spake thus: > In general, I'm not very fond of it, because its basically a dumping > grounds of random C-interface un-Perlish stuff that IMO, would be better > of put into smaller, better defined Perl modules. I couldn't agree more! Cheers! ---

Re: DateTime::Calendar::Julian doc bug

2003-02-27 Thread Dave Rolsky
On Fri, 28 Feb 2003, Rick Measham wrote: > On 28/2/03 3:52 pm, Dave Rolsky at [EMAIL PROTECTED] spake thus: > > Finally, I think that Perl's built-in int() function does everything that > > floor() is being used for. POSIX is a big memory hog, so getting rid of > > it is a good thing. > > Don't b

Re: DateTime::Calendar::Julian doc bug

2003-02-27 Thread Rick Measham
On 28/2/03 3:52 pm, Dave Rolsky at [EMAIL PROTECTED] spake thus: > Finally, I think that Perl's built-in int() function does everything that > floor() is being used for. POSIX is a big memory hog, so getting rid of > it is a good thing. Don't be too sure Dave ... years before 0 and the difference

DateTime::Calendar::Julian doc bug

2003-02-27 Thread Dave Rolsky
This won't work: # convert Julian->Gregorian... $dtgreg = DateTime->from_object( $dt ); It needs to be: $dtgreg = DateTime->from_object( object => $dt ); Since it inherits this method from DateTime.pm, the docs are wrong for itself as well. I noticed that it overrides _greg2rd and _rd2g

Re: ANNOUNCE: DateTime.pm 0.07

2003-02-27 Thread Dave Rolsky
On Thu, 27 Feb 2003, Eric Cholet wrote: > > - Added support for specifying a language by ISO code ("en" or > > "pt-br") as well as the subclass name. Based on a patch from Erich > > Cholet. > > Thanks, works great, I was able to switch my app to use DateTime's > strftime() with languages thanks t

Re: ANNOUNCE: DateTime.pm 0.07

2003-02-27 Thread Eric Cholet
--On Wednesday, February 26, 2003 23:10:58 -0600 Dave Rolsky <[EMAIL PROTECTED]> wrote: - Added support for specifying a language by ISO code ("en" or "pt-br") as well as the subclass name. Based on a patch from Erich Cholet. Thanks, works great, I was able to switch my app to use DateTime's str

Re: perl-date-time

2003-02-27 Thread Dave Rolsky
On Thu, 27 Feb 2003, fglock wrote: > About moving perl-date-time to CPAN: > The modules will be published by their authors or by > the project administrators? The authors, generally. > I suggest making a Bundle too. Sure, we just need to figure out what goes in it ;) -dave /*

Announce: Astro::Sunrise 0.8

2003-02-27 Thread Hill, Ronald
This is to announce a new version of Astro::Sunrise. This version replaces the dependency on Time::Object to Time::Piece. NAME Astro::Sunrise - Perl extension for computing the sunrise/sunset on a given day SYNOPSIS use Astro::Sunrise; ($sunrise, $sunset) = sunrise(,MM,DD,l

RE: perl-date-time

2003-02-27 Thread Hill, Ronald
[snipped] > > About moving perl-date-time to CPAN: > The modules will be published by their authors or by > the project administrators? > > I suggest making a Bundle too. This is a great Idea!! make them a bundle!! > > - Flávio S. Glock > > -- > In a parallel Dat

perl-date-time

2003-02-27 Thread fglock
About moving perl-date-time to CPAN: The modules will be published by their authors or by the project administrators? I suggest making a Bundle too. - Flávio S. Glock -- In a parallel DateTime: http://lwn.net/1998/0402/a/datetime.html published in CPAN as: http://sea

RE: There _is_ a (Gregorian) year 0

2003-02-27 Thread Peter J. Acklam
Dave Rolsky <[EMAIL PROTECTED]> wrote: > But in chapter 2 of Calendrical Calculations, they say: > > [...] Unlike the Julian calendar, this proleptic calendar > _does_ have a year 0. I think that's silly. It's a matter of _notation_, and only notation, whether one chooses to write years the his

Re: DateTime bug & default timezone

2003-02-27 Thread fglock
Dave Rolsky wrote: > So does anybody reading this object to me changing the default time zone > to UTC? I think UTC is better than floating here simply because it's > easier to explain. I understand that a 'floating' date object has less information on it than a 'UTC' date object, since the float

RE: There _is_ a (Gregorian) year 0

2003-02-27 Thread Peter J. Acklam
> Rick Measham <[EMAIL PROTECTED]> wrote: > > I figure that DateTime itself shouldn't be described as a > 'Gregorian' module, but as a 'Gregorian AD (or CE)' module. > This means there's a year 0 and -1 etc back to -INF. ¿Que? Why would "Gregorian AD module" imply that there is a year 0, -1, etc.

RE: There _is_ a (Gregorian) year 0

2003-02-27 Thread Peter J. Acklam
"Lawrence K. Hixson" <[EMAIL PROTECTED]> wrote: > > I found the reference on the web to this question which I > believe adds weight to Abigail's assertion: [...] Except that Abigail misses the fact that "AD" is a prefix whereas "BC" is a suffix. The year after 1 BC was AD 1, not 1 AD. She writ