RE: DateTime::Calendar::Julian doc bug
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 - 1;
}
Peter
--
Peter J. Acklam - [EMAIL PROTECTED] - http://home.online.no/~pjacklam
Re: DateTime::Calendar::Julian doc bug
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 int($_[0]) if (($_[0] >= 0) || (int($_[0]) == $_[0]));
return int($_[0]) -1;
}
There are 10 kinds of people:
those that understand binary, and those that don't.
The day Microsoft makes something that doesn't suck
is the day they start selling vacuum cleaners
Re: DateTime::Calendar::Julian doc bug
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! There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners
Re: DateTime::Calendar::Julian doc bug
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 be too sure Dave ... years before 0 and the difference is great.
> Consider this:
>
> use POSIX qw/floor/;
> print "int : " . int(-243.23) . "\n";
> # int : -243
> print "floor: " . floor(-243.23) . "\n";
> # floor: -244
Oh yeah, good point.
> If POSIX isn't brought in, then at least a local floor should be
> implemented:
>
> 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;
> }
That might be better. POSIX is pretty bulky, although you can save about
400KB or its 800KB if you just do "use POSIX ()" and don't let it import
all its crap into your namespace.
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.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: DateTime::Calendar::Julian doc bug
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 is great.
Consider this:
use POSIX qw/floor/;
print "int : " . int(-243.23) . "\n";
# int : -243
print "floor: " . floor(-243.23) . "\n";
# floor: -244
__END__
The module uses:
floor($y/4)
Where $y (year) could be a negative.
If POSIX isn't brought in, then at least a local floor should be
implemented:
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;
}
Cheers!
Rick
There are 10 kinds of people:
those that understand binary, and those that don't.
The day Microsoft makes something that doesn't suck
is the day they start selling vacuum cleaners
DateTime::Calendar::Julian doc bug
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 _rd2greg. I can rename these as _ymd2rd and _rd2ymd, so it won't look so odd in the Julian calendar modules. 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. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: ANNOUNCE: DateTime.pm 0.07
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 to the new ISO code mapping.
>
> BTW it's Eric not Erich.
Would you consider changing your name?
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: ANNOUNCE: DateTime.pm 0.07
--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
strftime() with languages thanks to the new ISO code mapping.
BTW it's Eric not Erich.
--
Eric Cholet
Re: perl-date-time
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 /*=== House Absolute Consulting www.houseabsolute.com ===*/
Announce: Astro::Sunrise 0.8
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,longitude,latitude,Time Zone,DST); ($sunrise, $sunset) = sunrise(,MM,DD,longitude,latitude,Time Zone,DST,ALT); ($sunrise, $sunset) = sunrise(,MM,DD,longitude,latitude,Time Zone,DST,ALT,inter); $sunrise = sun_rise(longitude,latitude); $sunset = sun_set(longitude,latitude); $sunrise = sun_rise(longitude,latitude,ALT); $sunset = sun_set(longitude,latitude,ALT); $sunrise = sun_rise(longitude,latitude,ALT,day_offset); $sunset = sun_set(longitude,latitude,ALT,day_offset); DESCRIPTION This module will return the sunrise/sunset for a given day. Eastern longitude is entered as a positive number Western longitude is entered as a negative number Northern latitude is entered as a positive number Southern latitude is entered as a negative number inter is set to either 0 or 1. If set to 0 no Iteration will occur. If set to 1 Iteration will occur. Default is 0. There are a number of sun altitides to chose from. The default is -0.833 because this is what most countries use. Feel free to specify it if you need to. Here is the list of values to specify altitude (ALT) with: 0 degrees Center of Sun's disk touches a mathematical horizon -0.25 degrees Sun's upper limb touches a mathematical horizon -0.583 degrees Center of Sun's disk touches the horizon; atmospheric refraction accounted for -0.833 degrees Sun's supper limb touches the horizon; atmospheric refraction accounted for -6 degrees Civil twilight (one can no longer read outside without artificial illumination) -12 degrees Nautical twilight (navigation using a sea horizon no longer possible) -15 degrees Amateur astronomical twilight (the sky is dark enough for most astronomical observations) -18 degrees Astronomical twilight (the sky is completely dark) USAGE sunrise "($sunrise, $sunset) = sunrise(,MM,DD,longitude,latitude,Time Zone,DST);" "($sunrise, $sunset) = sunrise(,MM,DD,longitude,latitude,Time Zone,DST,ALT);" Returns the sunrise and sunset times, in HH:MM format. (Note: Time Zone is the offset from GMT and DST is daylight savings time, 1 means DST is in effect and 0 is not). In the first form, a default altitude of -.0833 is used. In the second form, the altitude is specified as the last argument. Note that adding 1 to the Time Zone during DST and specifying DST as 0 is the same as indicating the Time Zone correctly and specifying DST as 1. Notes on Iteration ($sunrise, $sunset) = sunrise(,MM,DD,longitude,latitude,Time Zone,DST,ALT,inter); The orginal method only gives an approximate value of the Sun's rise/set times. The error rarely exceeds one or two minutes, but at high latitudes, when the Midnight Sun soon will start or just has ended, the errors may be much larger. If you want higher accuracy, you must then use the iteration feature. This feature is new as of version 0.7. Here is what I have tried to accomplish with this. a) Compute sunrise or sunset as always, with one exception: to convert LHA from degrees to hours, divide by 15.04107 instead of 15.0 (this accounts for the difference between the solar day and the sidereal day. b) Re-do the computation but compute the Sun's RA and Decl, and also GMST0, for the moment of sunrise or sunset last computed. c) Iterate b) until the computed sunrise or sunset no longer changes significantly. Usually 2 iterations are enough, in rare cases 3 or 4 iterations may be needed. *For Example* ($sunrise, $sunset) = sunrise( 2001, 3, 10, 17.384, 98.625, -5, 0 ); ($sunrise, $sunset) = sunrise( 2002, 10, 14, -105.181, 41.324, -7, 1, -18); ($sunrise, $sunset) = sunrise( 2002, 10, 14, -105.181, 41.324, -7, 1, -18, 1); =back sun_rise "$sun_rise = sun_rise( longitude, latitude );" "$sun_rise = sun_rise( longitude, latitude, ALT );" "$sun_rise = sun_rise( longitude, latitude, ALT, day_offset );" Returns the sun rise time for the given location. The first form uses today's da
RE: perl-date-time
[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 DateTime: > http://lwn.net/1998/0402/a/datetime.html > > published in CPAN as: > http://search.cpan.org/search?query=datetime+precise&mode=all >
perl-date-time
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://search.cpan.org/search?query=datetime+precise&mode=all
RE: There _is_ a (Gregorian) year 0
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 historical way (...,2 BC, 1 BC, AD 1, AD 2,...) or the astronomical way (...,-1, 0, 1, 2,...). Peter -- Peter J. Acklam - [EMAIL PROTECTED] - http://home.online.no/~pjacklam
Re: DateTime bug & default timezone
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 floating date doesn't have a timezone. That's why I would prefer the 'floating' default - it means 'timezone is not specified'. - Flavio S. Glock
RE: There _is_ a (Gregorian) year 0
> 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.? I'd say quite the opposite. "Gregorian AD module" sounds like a module which can only handle AD years. > There'd be a DateTime::Calendar::BCAD module which takes > years in the form /\d+\s*(B?CE?|AD)/. (OK, that's not > quite right but you get the idea) > > When converting one-to-the-other, then we get the > angst. Should 0 in DateTime be 1BC in ::BCAD or should it > be an error or should it be 0AD? There certainly is no "AD 0" neither in the historical AD/BC notation or the astronomical notation. Peter -- Peter J. Acklam - [EMAIL PROTECTED] - http://home.online.no/~pjacklam
RE: There _is_ a (Gregorian) year 0
"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 writes Peter -- Peter J. Acklam - [EMAIL PROTECTED] - http://home.online.no/~pjacklam
