Re: quick benchmarks DT vs. Date::Manip
On Mon, 24 Mar 2003, Joshua Hoblitt wrote: Maybe something like this should be added to the docs? -- diff -ur DateTime-0.08/lib/DateTime.pm new.DateTime/lib/DateTime.pm --- DateTime-0.08/lib/DateTime.pm 2003-03-20 20:02:27.0 -1000 +++ new.DateTime/lib/DateTime.pm2003-03-24 21:43:32.0 -1000 @@ -1347,7 +1347,8 @@ When given a CDateTime::Duration object, this method simply calls Cinvert() on that object and passes that new duration to the -Cadd_duration method. +Cadd_duration method. It is an optimization to to add a negative +duration rather than to subtract a positive one. =item * subtract( DateTime::Duration-new parameters ) I'm not sure it belongs in the docs, but if it does, then it probably belongs in an optimizations section because there's other things one can do to make DateTime run faster. The reason I'm not sure it belongs in the docs is that it may be better as part of the upcoming FAQ. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: quick benchmarks DT vs. Date::Manip
The reason I'm not sure it belongs in the docs is that it may be better as part of the upcoming FAQ. Or maybe a DateTime::Cookbook? -J --
Re: quick benchmarks DT vs. Date::Manip
On Mon, 24 Mar 2003, Joshua Hoblitt wrote: The reason I'm not sure it belongs in the docs is that it may be better as part of the upcoming FAQ. Or maybe a DateTime::Cookbook? Sure. I suppose the FAQ could be turned into POD somehow and included with each DateTime.pm release or something like that. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Request for DateTime API addition: today() constructor
On Mon, Mar 24, 2003 at 06:59:17PM -0600, Dave Rolsky wrote: On Mon, 24 Mar 2003, Joshua Hoblitt wrote: True. Though it'll be so commonly used I think it deserves a constructor. Ditto. It would also be nice if it defaults to current TZ instead of a floating time. The same for -now. Actually, both -now and -today default to UTC, because they use Time::Local::timegm internally. I would regularly need either of those so I think I'd like to see constructors for those four common forms. Perhaps: now_local() now_utc() today_local() today_utc Tim.
DateTime::Event::Sunrise Beta number 2
Hi All, I have just completed the beta 2 for the DtaeTime::Event::Sunrise module. Please test and let me know of any problems. I have changed the constructor to use named parameters. I also changed the names to use full names. Thanks for all of the suggestions! Ron Hill Sunrise.pm Description: Binary data
Fundamental addition request
I was wondering if you would consider making a fundamental
addition to DateTime. It would be to add the 'quarter' and
'day_of_quarter' to DateTime.
Attached is a patch to DateTime.xs, DateTime.pm and
t/03components.t. It is working for me, although t/09greg.t would
have to be changed too.
This patch would give you:
$dt-quarter # (1 - 4)
$dt-qtr # alias
$dt-day_of_quarter #(1 - max_days_in_quarter)
$dt-doq # alias
-Tim
diff -r -u DateTime-0.08/DateTime.xs DateTime-0.08.test/DateTime.xs
--- DateTime-0.08/DateTime.xs Sun Mar 16 21:36:12 2003
+++ DateTime-0.08.test/DateTime.xs Sun Mar 23 12:09:19 2003
@@ -73,8 +73,9 @@
PREINIT:
IV y, m;
IV c;
+IV quarter;
IV yadj = 0;
-IV dow, doy;
+IV dow, doy, doq;
IV rd_days;
PPCODE:
@@ -104,11 +105,13 @@
++y;
m -= 12;
}
+quarter = 1.0/3.1*m+1;
EXTEND(SP, extra ? 5 : 3);
PUSHs(sv_2mortal(newSViv(y)));
PUSHs(sv_2mortal(newSViv(m)));
PUSHs(sv_2mortal(newSViv(d)));
+PUSHs(sv_2mortal(newSViv(quarter)));
if (extra) {
dow = ((rd_days + 6) % 7) + 1;
@@ -116,11 +119,14 @@
if (_real_is_leap_year(y)) {
doy = PREVIOUS_MONTH_DOLY[m - 1] + d;
+ doq = doy-PREVIOUS_MONTH_DOLY[3*quarter-3];
} else {
doy = PREVIOUS_MONTH_DOY[m - 1] + d;
+ doq = doy-PREVIOUS_MONTH_DOY[3*quarter-3];
}
PUSHs(sv_2mortal(newSViv(doy)));
+ PUSHs(sv_2mortal(newSViv(doq)));
}
void
diff -r -u DateTime-0.08/lib/DateTime.pm DateTime-0.08.test/lib/DateTime.pm
--- DateTime-0.08/lib/DateTime.pm Thu Mar 20 22:02:27 2003
+++ DateTime-0.08.test/lib/DateTime.pm Mon Mar 24 08:21:04 2003
@@ -153,7 +153,7 @@
{
my $self = shift;
-@{ $self-{local_c} }{ qw( year month day day_of_week day_of_year ) } =
+@{ $self-{local_c} }{ qw( year month day quarter day_of_week day_of_year
day_of_quarter) } =
$self-_rd2ymd( $self-{local_rd_days}, 1 );
@{ $self-{local_c} }{ qw( hour minute second ) } =
@@ -292,6 +292,9 @@
*day = \day_of_month;
*mday = \day_of_month;
+sub quarter {$_[0]-{local_c}{quarter} };
+*qtr = \quarter;
+
sub day_of_month_0 { $_[0]-{local_c}{day} - 1 }
*day_0 = \day_of_month_0;
*mday_0 = \day_of_month_0;
@@ -308,6 +311,11 @@
sub day_abbr { $_[0]-{language}-day_abbreviation( $_[0] ) }
+sub day_of_quarter { $_[0]-{local_c}{day_of_quarter} }
+*doq = \day_of_quarter;
+*day_of_qtr = \day_of_quarter;
+
+
sub day_of_year { $_[0]-{local_c}{day_of_year} }
*doy = \day_of_year;
@@ -849,6 +857,12 @@
$doy= $dt-day_of_year# 1-366 (leap years)
# also $dt-doy
+
+ $doq= $dt-day_of_quarter # 1-(number of days)
+ # also $dt-doq, $dt-day_of_qtr
+
+ $qtr= $dt-quarter# 1-4
+ # also $dt-qtr
# all of the start-at-1 methods above have correponding start-at-0
# methods, such as $dt-day_of_month_0, $dt-month_0 and so on
diff -r -u DateTime-0.08/t/03components.t DateTime-0.08.test/t/03components.t
--- DateTime-0.08/t/03components.t Tue Mar 11 23:43:25 2003
+++ DateTime-0.08.test/t/03components.t Sun Mar 23 12:24:21 2003
@@ -1,6 +1,6 @@
use strict;
-use Test::More tests = 72;
+use Test::More tests = 74;
use DateTime;
@@ -16,6 +16,7 @@
is( $d-year, 2001, '-year' );
is( $d-ce_year, 2001, '-ce_year' );
is( $d-month, 7, '-month' );
+is( $d-quarter,3,'-quarter');
is( $d-month_0, 6, '-month_0' );
is( $d-month_name, 'July', '-month' );
is( $d-month_abbr, 'Jul', '-month' );
@@ -35,6 +36,7 @@
is( $d-day_of_year, 186, '-day_of_year' );
is( $d-day_of_year_0, 185, '-day_of_year' );
+is( $d-day_of_quarter, 5, '-day_of_quarter' );
is( $d-day_of_week, 4, '-day_of_week' );
is( $d-day_of_week_0, 3, '-day_of_week' );
is( $d-wday, 4, '-wday' );
Calsys Lang Namespaces
Greetings, I was considering the issue of languages and calendar systems and would like to get some input from the group on the matter. Taking DateTime::Calendar::Ethiopic as a specific example, should languages then go under DateTime::Calendar::Ethiopic::Language::locale ? Versus possibly DateTime::Language::Calendar::Ethiopic::locale ? I favor the first option, but then I also favor Gregorian:: as a name space and no default calendar system being assumed... ;-) Actually, if Gregorian modules and data went under ::Calendar::Gregorian:: and ::Calendar::Gregorian::Language:: the issue goes away I think. But if that is not going to happen, would a DateTime::Calendar::Ethiopic::Language module really be needed or should we rely on DateTime::Language to know the calendar system and do the right thing? thanks, /Daniel
DateTime::Event::Sunrise Beta number 3
Hi All,
I have just completed the third beta for the Sunrise module. I have added
a set method (no documentation yet)I used the set API from
Rick's easter module (Thanks Rick!!)Here is the perl
script I used to test:
#!/usr/bin/perl
use strict;
use warnings;
use DateTime;
use DateTime::Event::Sunrise;
my $dt1 = DateTime-new( year = 2000,
month = 6,
day= 20,
);
my $dt2 = DateTime-new( year = 2000,
month = 11,
day= 20,
);
my $sunrise = DateTime::Event::Sunrise -new(
Longitude ='-118' ,
Latitude = '33',
);
my @set = $sunrise-set(from=$dt1, to=$dt2, inclusive=0);
foreach my $tmp(@set) {
$tmp-set_time_zone( 'America/Los_Angeles' );
print $tmp-datetime .\n;
}
This will be the last beta for this. Unless there is an API change
request.
Any problems please let me know.
Thanks
Ron Hill
Sunrise.pm
Description: Binary data
Re: Calsys Lang Namespaces
Daniel Yacob schreef:
I favor the first option, but then I also favor Gregorian:: as a name
space and no default calendar system being assumed... ;-)
Unfortunately, us kalandariophiles are a minority on this list; I
suspect Dave in particular of wanting to use DateTime for all kinds of
worldy, modern, boring stuff.
But if that is not going to happen, would a
DateTime::Calendar::Ethiopic::Language module really be needed or
should we rely on DateTime::Language to know the calendar system
and do the right thing?
No, DateTime::Language can't know about all the wonderful calendars in
the world. For most calendars (including Ethiopic, I presume) one or
two languages will suffice: one in the local alphabet, and one
transcribed to the Roman alphabet. The latter should then be included
in all language modules...
Or do the Ethiopic months have English names? (Or Italian, perhaps?)
It would be nice if one could pass for example a
DateTime::Language::Dutch object to DT::C::Ethiopic, which would then do
the right thing. Something like:
sub new {
my $class = shift;
my $args = validate( @_,
{ ...,
language = { type = SCALAR | OBJECT,
default = 'Amharic' }
}
);
...
if ( ref $args{language} ) {
$self-{language} = ($args{language} eq 'Amharic' ?
'Amharic' : 'Roman');
}
...
}
sub month_name {
my $self = shift;
return { Roman = ['month1', 'month2', ... ],
Amharic = [\x{12XX}\x{13XX}, ... ], }
-{$self-{language}}[$self-month_0];
}
(Or move those month names to their own module DT::C::E::Language; but
that's an implementation detail. I would like to have a consistent API
for all calendars, but I don't care about the implementations.)
Eugene
DateTime::Event::Easter - Beta 2
Attached is Beta 2. I think I've incorporated all suggestions. If I've missed anything, let me know. Beta 2 includes support for Orthodox Easter, however I doubt it handles it the best way possible. Please take a look and offer suggestions (its the last sub before the POD). It should also be noted that both Easters should return Gregorian Dates as they do now. I've renamed the two Easters as 'western' and 'eastern'. This is still probably not the best names but its better than my mistake concerning Orthodox easter in the previous release :). If anyone can help with names that relate I'd love it. I considered 'western' and 'orthodox', but I'd prefer names that are related. The -set method is now -as_list and I've added -as_set which returns a DateTime::Set object (although this isn't tested at ALL! CPAN wouldn't give me DateTime::Set :)) The cache has been removed. This means years are sometimes recalculated a second later, but the memory blow-out factor isn't there. Thanks for all the suggestions, 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 Write a wise proverb and your name will live forever. -- Anonymous Easter.pm Description: Binary data
RE: DateTime::Event::Easter - Beta 2
Hi Rick, [snipped] The -set method is now -as_list and I've added -as_set which returns a DateTime::Set object (although this isn't tested at ALL! CPAN wouldn't give me DateTime::Set :)) I guess I jumped the gun a bit, I will follow suit and make the changes to the Sunrise module. Does anyone know where I can get the DateTime::Set module? Thanks for all the suggestions, Cheers! Rick --
Re: DateTime::Event::Easter - Beta 2
Hill, Ronald wrote: Does anyone know where I can get the DateTime::Set module? It is in the cvs (http://sourceforge.net -- project perl-date-time). I'll update CPAN now. - Flavio S. Glock
Re: DateTime::Event::Sunrise Beta number 3
On Tue, 25 Mar 2003, Hill, Ronald wrote: my $sunrise = DateTime::Event::Sunrise -new( Longitude ='-118' , Latitude = '33', ); For consistency with other DateTime modules, it'd be good if the parameter names were lower case. A couple others nits: $VERSION = qw($Revision: 0.01 $) [1]; That's not CVS, is it? If it is, please don't use it's revision numbers directly (this is discussed in the dev docs I wrote). Otherwise it looks good to me. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Event::Easter - Beta 2
I'm going to pick nits, because I'm anal. - It'd be good to name the variables that are constants either in all caps or in StudlyCaps - You don't need to load Data::Dumper - Your editor produces satanic tabbing indentation! What are you using? When I load the code in emacs or vi it scrolls off the screen and nothing lines up. - You don't need to copy the validate into as_set. It's ok if it blows up elsewhere since (hopefully) the Params::Validate-generated error message will be clear enough to indicate the problem anyway. - fullmoon is two words so it should be full_moon. But maybe this parameter should be changed to something like church? After all, people don't think of the Easter full moon. - The docs need to say what the default for the inclusive parameter is (it's implied, but not stated). Otherwise it looks good, modulo bugs ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Event::Easter - Beta 2
Thanks Eugene! This is excellent! On 26/3/03 8:42 am, Eugene van der Pijll at [EMAIL PROTECTED] spake thus: Rick Measham schreef: Beta 2 includes support for Orthodox Easter, however I doubt it handles it the best way possible. Please take a look and offer suggestions (its the last sub before the POD). It should also be noted that both Easters should return Gregorian Dates as they do now. The $potential_easter shouldn't be in eastern_easter. When called with year = 6, the result is an infinite loop: [snip] I'll have a look at that, thanks What do you do with years without an Easter? Try the year 35000: [snip] And what about the years with 2 Easters? Do your 'following' and 'previous' work for them? It looks like they work by changing the year by one... Actually I woke up about 3am in a cold sweat realizing the possibility of other-than-one-easter years. Best solution would perhaps to convert to Julian at the start of those methods, and to convert them back to Gregorian at the end. (DateTime::Calendar::Julian could be useful here ;-) Yeah, I figured I might have to do that, although then rather than finding the Easter in Julian Year 35000, I need to find it between Julian Equivalents of Gregorian Jan 1 35000 and Gregorian Dec 31 35000. Which just isn't so easy as calling it with a year. I'll need to call the potential (three?) years that overlap the single Gregorian year, and then find the Easter that intersects with the Gregorian year. Hmmm .. I see some use for DateTime::Set::intersect there... Anyways, because Orthodox dates require so much extra coding, and because they require other modules, I'm considering breaking this into two modules. if I do that, I'll also make DateTime::Event::OrthodoxEaster able to accept both DateTime objects and DateTime::Calendar::Julian objects. This will mean most people who only want 'Western' Easter only need DateTime::Event::Easter. And they'll only need DateTime::Set if they use -as_set Speaking of which: Is there any better way to conditionally load a module other than: eval(use DateTime::Set); croak(Couldn't load DateTime::Set:.$@) if $@; And some small points: - Documentation bug: 'fullmoon' should be 'easter' in the constructor options. Thankyou, fixed - In the POD, your lines are longer than 80chars, which is a bit annoying. LOL .. BBEdit's Hard Wrap is about to be sicked on the docs ... stand back. Thanks for all this, 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
Re: DateTime::Event::Easter - Beta 2
On 26/3/03 9:09 am, Dave Rolsky at [EMAIL PROTECTED] spake thus: I'm going to pick nits, because I'm anal. Picking nits is good, but I swear I showered and combed my hair this morning! - It'd be good to name the variables that are constants either in all caps or in StudlyCaps Will do - You don't need to load Data::Dumper Oh poo! As you can guess I had it there for debugging at one point - Your editor produces satanic tabbing indentation! What are you using? When I load the code in emacs or vi it scrolls off the screen and nothing lines up. Satan will be removed. I'll make it 3 spaces rather than 1-tab or whatever was in what I've pasted in. - You don't need to copy the validate into as_set. It's ok if it blows up elsewhere since (hopefully) the Params::Validate-generated error message will be clear enough to indicate the problem anyway. OK, thanks for the clarification - fullmoon is two words so it should be full_moon. But maybe this parameter should be changed to something like church? After all, people don't think of the Easter full moon. The parameter has changed to 'easter', and accepts 'eastern' or 'western', Eugene pointed out that I'd left that in the docs. I'll hunt it down and kill it. - The docs need to say what the default for the inclusive parameter is (it's implied, but not stated). Ahh, OK. Actually the docs are currently written aimed at testing. There's no licence information or cross references to other modules or cookbook examples or... Anyways, what I'm saying is that I'll specifically say something like: If no 'easter' parameter is supplied then 'western' will be assumed. Thanks for this, 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
Re: Fundamental addition request
Eugene van der Pijll wrote:
Tim Allwine schreef:
I was wondering if you would consider making a fundamental
addition to DateTime. It would be to add the 'quarter' and
'day_of_quarter' to DateTime.
RGH! Please no! 'week' and 'day_of_year' were two of the hardest
methods to write in DT::C::Christian, and now you want to add more of
that kind!
But now seriously:
(in _rd2ymd:)
PUSHs(sv_2mortal(newSViv(y)));
PUSHs(sv_2mortal(newSViv(m)));
PUSHs(sv_2mortal(newSViv(d)));
+PUSHs(sv_2mortal(newSViv(quarter)));
if (extra) {
dow = ((rd_days + 6) % 7) + 1;
..
PUSHs(sv_2mortal(newSViv(doy)));
+ PUSHs(sv_2mortal(newSViv(doq)));
}
Even though _rd2ymd is an internal function, please don't change the
return values. Put 'quarter' at the end. It doesn't need to be set for
all datetime's, so it's OK if it's inside the if(extra){}. Like week and
doy, it's a superfluous variable: y, m, and d are sufficient to define a
date.
+@{ $self-{local_c} }{ qw( year month day quarter day_of_week day_of_year day_of_quarter) } =
So this becomes
+@{ $self-{local_c} }{ qw( year month day day_of_week day_of_year quarter day_of_quarter) } =
OK, fixed. It even passes all tests now.
-Tim
diff -r -u DateTime-0.08/DateTime.xs DateTime-0.08.test/DateTime.xs
--- DateTime-0.08/DateTime.xs Sun Mar 16 21:36:12 2003
+++ DateTime-0.08.test/DateTime.xs Tue Mar 25 12:44:39 2003
@@ -73,8 +73,9 @@
PREINIT:
IV y, m;
IV c;
+IV quarter;
IV yadj = 0;
-IV dow, doy;
+IV dow, doy, doq;
IV rd_days;
PPCODE:
@@ -111,16 +112,21 @@
PUSHs(sv_2mortal(newSViv(d)));
if (extra) {
+ quarter = 1.0/3.1*m+1;
dow = ((rd_days + 6) % 7) + 1;
PUSHs(sv_2mortal(newSViv(dow)));
if (_real_is_leap_year(y)) {
doy = PREVIOUS_MONTH_DOLY[m - 1] + d;
+ doq = doy-PREVIOUS_MONTH_DOLY[3*quarter-3];
} else {
doy = PREVIOUS_MONTH_DOY[m - 1] + d;
+ doq = doy-PREVIOUS_MONTH_DOY[3*quarter-3];
}
PUSHs(sv_2mortal(newSViv(doy)));
+ PUSHs(sv_2mortal(newSViv(quarter)));
+ PUSHs(sv_2mortal(newSViv(doq)));
}
void
diff -r -u DateTime-0.08/lib/DateTime.pm DateTime-0.08.test/lib/DateTime.pm
--- DateTime-0.08/lib/DateTime.pm Thu Mar 20 22:02:27 2003
+++ DateTime-0.08.test/lib/DateTime.pm Tue Mar 25 12:48:04 2003
@@ -153,7 +153,7 @@
{
my $self = shift;
-@{ $self-{local_c} }{ qw( year month day day_of_week day_of_year ) } =
+@{ $self-{local_c} }{ qw( year month day day_of_week day_of_year quarter
day_of_quarter) } =
$self-_rd2ymd( $self-{local_rd_days}, 1 );
@{ $self-{local_c} }{ qw( hour minute second ) } =
@@ -292,6 +292,9 @@
*day = \day_of_month;
*mday = \day_of_month;
+sub quarter {$_[0]-{local_c}{quarter} };
+*qtr = \quarter;
+
sub day_of_month_0 { $_[0]-{local_c}{day} - 1 }
*day_0 = \day_of_month_0;
*mday_0 = \day_of_month_0;
@@ -308,6 +311,11 @@
sub day_abbr { $_[0]-{language}-day_abbreviation( $_[0] ) }
+sub day_of_quarter { $_[0]-{local_c}{day_of_quarter} }
+*doq = \day_of_quarter;
+*day_of_qtr = \day_of_quarter;
+
+
sub day_of_year { $_[0]-{local_c}{day_of_year} }
*doy = \day_of_year;
@@ -849,6 +857,12 @@
$doy= $dt-day_of_year# 1-366 (leap years)
# also $dt-doy
+
+ $doq= $dt-day_of_quarter # 1-(number of days)
+ # also $dt-doq, $dt-day_of_qtr
+
+ $qtr= $dt-quarter# 1-4
+ # also $dt-qtr
# all of the start-at-1 methods above have correponding start-at-0
# methods, such as $dt-day_of_month_0, $dt-month_0 and so on
@@ -1135,6 +1149,14 @@
=item * day_of_year, doy
Returns the day of the year.
+
+=item * day_of_quarter, doq
+
+Returns the day of the quarter.
+
+=item * quarter, qtr
+
+Returns the quarter of the year.
=item * ymd( $optional_separator ), date
diff -r -u DateTime-0.08/t/03components.t DateTime-0.08.test/t/03components.t
--- DateTime-0.08/t/03components.t Tue Mar 11 23:43:25 2003
+++ DateTime-0.08.test/t/03components.t Sun Mar 23 12:24:21 2003
@@ -1,6 +1,6 @@
use strict;
-use Test::More tests = 72;
+use Test::More tests = 74;
use DateTime;
@@ -16,6 +16,7 @@
is( $d-year, 2001, '-year' );
is( $d-ce_year, 2001, '-ce_year' );
is( $d-month, 7, '-month' );
+is( $d-quarter,3,'-quarter');
is( $d-month_0, 6, '-month_0' );
is( $d-month_name, 'July', '-month' );
is( $d-month_abbr, 'Jul', '-month' );
@@ -35,6 +36,7 @@
is( $d-day_of_year, 186, '-day_of_year' );
is( $d-day_of_year_0, 185, '-day_of_year' );
+is( $d-day_of_quarter, 5, '-day_of_quarter' );
is( $d-day_of_week, 4, '-day_of_week' );
is( $d-day_of_week_0, 3, '-day_of_week' );
is( $d-wday, 4, '-wday' );
Re: DateTime::Event::Easter - Beta 2
Rick Measham schreef: Best solution would perhaps to convert to Julian at the start of those methods, and to convert them back to Gregorian at the end. (DateTime::Calendar::Julian could be useful here ;-) Yeah, I figured I might have to do that, although then rather than finding the Easter in Julian Year 35000, I need to find it between Julian Equivalents of Gregorian Jan 1 35000 and Gregorian Dec 31 35000. Which just isn't so easy as calling it with a year. I'll need to call the potential (three?) years that overlap the single Gregorian year, and then find the Easter that intersects with the Gregorian year. Hmmm .. I see some use for DateTime::Set::intersect there... Only if you have (public) functions that are called with a year. If not, you can convert to Julian at the start of following(); call easter() with the Julian year; convert back to Gregorian. The Orthodox Easter is always in the second quarter of the Julian year (though not always in Spring), and there's always only one per year. If eastern_easter is a public function (it is not documented), I suggest a small piece of POD: =item * eastern_easter( $year ) This function returns the Eastern Orthodox Easter in year $year. Note: The calculation of Easter uses the Julian calendar. This method therefore returns the date of Easter that falls in the Julian year $year. In the Gregorian calendar, this Easter can lie in a different year. If this bothers you, don't use dates before 10624 BC or after 33807 AD. Speaking of which: Is there any better way to conditionally load a module other than: eval(use DateTime::Set); croak(Couldn't load DateTime::Set:.$@) if $@; Block-eval is better than string-eval. Also I think 'require' is used more often than 'use' in these kind of constructs, but I don't think there's a material difference. And some small points: Before I forget: the file had MS-DOS line endings, and no EOL on the last line. this confused my vi. Eugene
Re: DateTime::Event::Easter - Beta 2
On Tue, 25 Mar 2003, Eugene van der Pijll wrote: other than: eval(use DateTime::Set); croak(Couldn't load DateTime::Set:.$@) if $@; Block-eval is better than string-eval. Also I think 'require' is used more often than 'use' in these kind of constructs, but I don't think there's a material difference. You can't block-eval a use, since use is handled at compile time. This could be done as: require DateTime::Set , since calling DateTime::Set-import isn't necessary. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Event::Easter - Beta 2
On 26/3/03 9:44 am, Eugene van der Pijll at [EMAIL PROTECTED] spake thus: Rick Measham schreef: Best solution would perhaps to convert to Julian at the start of those methods, and to convert them back to Gregorian at the end. (DateTime::Calendar::Julian could be useful here ;-) Yeah, I figured I might have to do that, although then rather than finding the Easter in Julian Year 35000, I need to find it between Julian Equivalents of Gregorian Jan 1 35000 and Gregorian Dec 31 35000. Which just isn't so easy as calling it with a year. I'll need to call the potential (three?) years that overlap the single Gregorian year, and then find the Easter that intersects with the Gregorian year. Hmmm .. I see some use for DateTime::Set::intersect there... Only if you have (public) functions that are called with a year. If not, you can convert to Julian at the start of following(); call easter() with the Julian year; convert back to Gregorian. The Orthodox Easter is always in the second quarter of the Julian year (though not always in Spring), and there's always only one per year. I'll give that a go, see what happens If eastern_easter is a public function (it is not documented), I suggest a small piece of POD: It's not public, unlike western_easter (which can be exported as 'easter', although I've never tested this!) Speaking of which: Is there any better way to conditionally load a module other than: eval(use DateTime::Set); croak(Couldn't load DateTime::Set:.$@) if $@; Block-eval is better than string-eval. Also I think 'require' is used more often than 'use' in these kind of constructs, but I don't think there's a material difference. Can't use a block eval for 'use X'. All 'use X' commands are parsed before anything else, so it will always try to use X, even if we don't go there. 'require X' happens at run-time so doesn't need to be eval-ed. BUT, does 'require' do all that I need it to do? I know it doesn't import for one. And some small points: Before I forget: the file had MS-DOS line endings, and no EOL on the last line. this confused my vi. ROFL! I'm creating this on a mac with unix line endings. Maybe my mail program changed it! Hmm .. maybe I should send it some other way. 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
Re: DateTime::Event::Easter - Beta 2
Rick Measham schreef:
Can't use a block eval for 'use X'. All 'use X' commands are parsed before
anything else, so it will always try to use X, even if we don't go there.
Yes, of course, stupid me.
'require X' happens at run-time so doesn't need to be eval-ed.
Except if you want to catch the error if the module isn't installed.
BUT, does
'require' do all that I need it to do? I know it doesn't import for one.
perldoc -f use. 'use' is exactly equivalent to
BEGIN { require Module; import Module LIST; }
Before I forget: the file had MS-DOS line endings, and no EOL on the
last line. this confused my vi.
ROFL! I'm creating this on a mac with unix line endings. Maybe my mail
program changed it! Hmm .. maybe I should send it some other way.
No, my mistake again. They were probably mac line endings, but I don;'t
encounter them enough to recognize them.
Eugene
ANNOUNCE: DateTime::TimeZone 0.11
0.11 2003-03-26 the Asia/Baghdad release - Fixed two bugs, both of which made some time zones unusable.. One affected time zones that do not have any DST changes, and the other affected time zones that have exactly two historical offsets (one of which would be the current offset), such as Pacific/Tarawa. Reported by Eric Cholet. This bug doesn't affect the majority of the world's most populated areas, but it still affects more than a few time zones. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: ICal and timezones
* Joshua Hoblitt ([EMAIL PROTECTED]) [26 Mar 2003 18:05]:
* Dave Rolsky wrote:
[...]
Certainly. I was just proposing returning something _correct_, but a bit
unexpected.
Something like this? I'll added tests if requested.
Or the other option:
(I make a clone so as to not disturb any setting the original may have)
Index: lib/DateTime/Format/ICal.pm
===
RCS file:
/cvsroot/perl-date-time/modules/DateTime-Format-ICal/lib/DateTime/Format/ICal.pm,v
retrieving revision 1.6
diff -u -r1.6 ICal.pm
--- lib/DateTime/Format/ICal.pm 16 Feb 2003 17:23:01 - 1.6
+++ lib/DateTime/Format/ICal.pm 26 Mar 2003 07:28:47 -
@@ -131,6 +131,10 @@
{
return 'TZID=' . $tz-name . ':' . $base;
}
+
+my $rdt = $dt-clone;
+$rdt-set_time_zone( 'UTC' );
+return $self-format_datetime( $rdt );
}
sub format_duration
Index: t/01datetime.t
===
RCS file: /cvsroot/perl-date-time/modules/DateTime-Format-ICal/t/01datetime.t,v
retrieving revision 1.3
diff -u -r1.3 01datetime.t
--- t/01datetime.t 15 Feb 2003 06:01:54 - 1.3
+++ t/01datetime.t 26 Mar 2003 07:28:47 -
@@ -1,7 +1,8 @@
use strict;
-use Test::More tests = 33;
+use Test::More tests = 34;
+use DateTime;
use DateTime::Format::ICal;
my $ical = 'DateTime::Format::ICal';
@@ -76,3 +77,7 @@
is( $ical-format_datetime($dt), 'TZID=America/Chicago:00241121', 'output should
match input' );
}
+{
+my $dt = DateTime-new(qw( year 1996 month 03 day 16 hour 13 minute 23 second 4
time_zone +1100 ));
+is( $ical-format_datetime($dt), '19960316T022304Z', 'output should match input'
);
+}
Re: Fundamental addition request
Tim Allwine schreef:
I was wondering if you would consider making a fundamental
addition to DateTime. It would be to add the 'quarter' and
'day_of_quarter' to DateTime.
RGH! Please no! 'week' and 'day_of_year' were two of the hardest
methods to write in DT::C::Christian, and now you want to add more of
that kind!
But now seriously:
(in _rd2ymd:)
PUSHs(sv_2mortal(newSViv(y)));
PUSHs(sv_2mortal(newSViv(m)));
PUSHs(sv_2mortal(newSViv(d)));
+PUSHs(sv_2mortal(newSViv(quarter)));
if (extra) {
dow = ((rd_days + 6) % 7) + 1;
..
PUSHs(sv_2mortal(newSViv(doy)));
+ PUSHs(sv_2mortal(newSViv(doq)));
}
Even though _rd2ymd is an internal function, please don't change the
return values. Put 'quarter' at the end. It doesn't need to be set for
all datetime's, so it's OK if it's inside the if(extra){}. Like week and
doy, it's a superfluous variable: y, m, and d are sufficient to define a
date.
+@{ $self-{local_c} }{ qw( year month day quarter day_of_week day_of_year
day_of_quarter) } =
So this becomes
+@{ $self-{local_c} }{ qw( year month day day_of_week day_of_year quarter
day_of_quarter) } =
Eugene
Re: Request for DateTime API addition: today() constructor
On Tue, 25 Mar 2003, Tim Bunce wrote: On Mon, Mar 24, 2003 at 06:59:17PM -0600, Dave Rolsky wrote: On Mon, 24 Mar 2003, Joshua Hoblitt wrote: True. Though it'll be so commonly used I think it deserves a constructor. Ditto. It would also be nice if it defaults to current TZ instead of a floating time. The same for -now. Actually, both -now and -today default to UTC, because they use Time::Local::timegm internally. I would regularly need either of those so I think I'd like to see constructors for those four common forms. Perhaps: now_local() now_utc() today_local() today_utc Why not have the constructors take any timezone as an argument? -now( 'utc' ) or -now( timezone = 'local' ) or even -now( timezone = 'floating' ) If no arguments are specified you get still get UTC. Cheers, -J --
RE: DateTime::Event::Easter - Beta 2
Hi Rick,
Attached is Beta 2. I think I've incorporated all suggestions. If
I've missed anything, let me know.
[snipped]
The -set method is now -as_list and I've added -as_set which
returns a DateTime::Set object (although this isn't tested at ALL!
CPAN wouldn't give me DateTime::Set :))
looking at your module you need to add the
use DateTime::Set to your script
Also here:
sub as_set {
my $self = shift;
# Maybe we should validate here otherwise its as_list that will
complain
return DateTime::Set-new( dates = [ $self-as_list(@_) ] );
}
I added this to my module and it did not complain :-) So do I still
need to do some validation?
Also under the SYNOPSIS section of the pod you still have
@set = $palm_sunday-set(from=$dt, to=$dt2, inclusive=1);
need to change that to
@set = $palm_sunday-as_list(from=$dt, to=$dt2, inclusive=1);
The cache has been removed. This means years are sometimes
recalculated a second later, but the memory blow-out factor isn't
there.
Thanks for all the suggestions,
Cheers!
Rick
You have done a great job on this module!! it looks good.
Thanks
Ron Hill
Re: Quick question: fractional seconds
On Tue, 25 Mar 2003, John Siracusa wrote: What's the status of fractional seconds? Static ;) As in not being worked on because I have no idea what do with it ;) Proposals, and even better, patches, are welcome. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Event::Easter - Beta 2
Rick Measham schreef:
Beta 2 includes support for Orthodox Easter, however I doubt it
handles it the best way possible. Please take a look and offer
suggestions (its the last sub before the POD). It should also be
noted that both Easters should return Gregorian Dates as they do now.
The $potential_easter shouldn't be in eastern_easter. When called with
year = 6, the result is an infinite loop:
Called with year 6, result is 60001-06-24
Called with year 5, result is 6-07-02
Called with year 59998, result is 5-06-13
Called with year 59997, result is 59998-06-28
Called with year 59996, result is 59997-07-06
ad infinitum
Unless I understand the eastern_easter function incorrectly, the loop
should be in _easter:
sub _easter {
my $self = shift;
my $year = shift;
if ($self-{easter} eq 'eastern') {
my $date;
my $y = $year;
do {
$date = eastern_easter($y);
$y += ($year = $date-year);
} until ($date-year == $year);
return $date;
} else {
western_easter($year);
}
}
What do you do with years without an Easter? Try the year 35000:
Called with year 35000, result is 35001-01-04
Called with year 34999, result is 34999-12-15
Called with year 35000, result is 35001-01-04
Called with year 34999, result is 34999-12-15
Called with year 35000, result is 35001-01-04
etc.
And what about the years with 2 Easters? Do your 'following' and
'previous' work for them? It looks like they work by changing the year
by one...
Best solution would perhaps to convert to Julian at the start of those
methods, and to convert them back to Gregorian at the end.
(DateTime::Calendar::Julian could be useful here ;-)
And some small points:
- Documentation bug: 'fullmoon' should be 'easter' in the constructor
options.
- In the POD, your lines are longer than 80chars, which is a bit
annoying.
Eugene
Re: Calsys Lang Namespaces
On Tue, 25 Mar 2003, Eugene van der Pijll wrote: Unfortunately, us kalandariophiles are a minority on this list; I suspect Dave in particular of wanting to use DateTime for all kinds of worldy, modern, boring stuff. Well, I'm interested in other calendars as well. My wife's Taiwanese so I've been meaning to get around to working on DateTime::Calendar::Chinese in honor of her ;) No, DateTime::Language can't know about all the wonderful calendars in the world. For most calendars (including Ethiopic, I presume) one or two languages will suffice: one in the local alphabet, and one transcribed to the Roman alphabet. The latter should then be included in all language modules... Exactly what I was thinking. We can't expect people who create DateTime::Language::Dutch to also provide Dutch names for the Ethiopic calendar's months. So you're probably stuck with your own little hierarchy of DateTime::Calendar::Ethiopic::Language modules. Whee, 5 levels of namespace! I expect Ethiopic is something of an exception, in that it'll probably require a fair number of language modules. But for something like the Chinese calendar, I'm planning to offer Romanized Mandarin and Unicode Traditional Chinese, and then people can convert from the latter as needed. (Or move those month names to their own module DT::C::E::Language; but that's an implementation detail. I would like to have a consistent API for all calendars, but I don't care about the implementations.) Yes, API consistency inasmuch as it is possible is a good thing. It'll probably take a few different DateTime::Calendar modules before we can figure out exactly what this should look like, though. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
