Re: Fw: Hijri dates
Claus Tondering's calendar FAQ[1] has some information about this in sections 4.2 and 4.5. 4.5 says that Saudi Arabia has adopted a calendar based on a calculated astronomical moon (at Mecca). This is actually the reason that I wanted to get a Moonrise package working... -ben
RE: Fw: Hijri dates
Hi Ben, [snipped] This is actually the reason that I wanted to get a Moonrise package working... -ben I tried, I failed, I surrender!! Ron
Re: Bug in DateTime::Span-contains()
It works for me:
2003-05-10T06:13:00
(I had to manually remove the old DT::E:Sunrise installation,
don't know why)
- Flavio S. Glock
Hill, Ronald wrote:
Can someone test this script below using the sunrise module
that is located in CVS?
Please advise!
Ron Hill
use strict;
use warnings;
use DateTime;
use Datetime::Event::Sunrise;
my $dt = DateTime-new(year = 2003,
month =05,
day =10,
);
my $sunrise = DateTime::Event::Sunrise -sunrise(
longitude = 114.18,
latitude= 22.33,
);
my $rise= $sunrise-current($dt);
$rise-set_time_zone('Asia/Hong_Kong');
print $rise-datetime;
RE: Bug in DateTime::Span-contains()
Hi Flavio, It works for me: 2003-05-10T06:13:00 (I had to manually remove the old DT::E:Sunrise installation, don't know why) - Flavio S. Glock [snipped] Great!! At least that tells me the bug in my module is fixed :) Are you using DateTime-Set version 0.07 and DateTime 0.12? (I need to update the pre req's for sunrise) I wish we could get the DateTime.pm to work on windows. Thanks Flavio Ron Hill
RE: Bug in DateTime::Span-contains()
On Fri, 30 May 2003, Hill, Ronald wrote: Great!! At least that tells me the bug in my module is fixed :) Are you using DateTime-Set version 0.07 and DateTime 0.12? (I need to update the pre req's for sunrise) I wish we could get the DateTime.pm to work on windows. Have you tried the latest CVS version? It's getting closer, I just need some help debugging the problems. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [PATCH] DT::Language alternate namespaces
On Thu, 29 May 2003, Joshua Hoblitt wrote: Uh, they could just call it DT::Language::MyLanguage, right? Do we really want people including DT::Language::* modules in there distributions? If it was something like DT::Language::Custom::Foo, I probably wouldn't care. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
RE: Bug in DateTime::Span-contains()
Hi Dave, On Fri, 30 May 2003, Hill, Ronald wrote: Great!! At least that tells me the bug in my module is fixed :) Are you using DateTime-Set version 0.07 and DateTime 0.12? (I need to update the pre req's for sunrise) I wish we could get the DateTime.pm to work on windows. Have you tried the latest CVS version? It's getting closer, I just need some help debugging the problems. Just like before!!! G:\modules\DateTime.pmnmake test Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. F:\perl\bin\Perl.exe -Mblib -IF:\Perl\lib -IF:\Perl\lib -e use Test::Harness qw(runte verbose); $verbose=0; runtests @ARGV; t\00load.t t\01sanity.t t\02last_day.t t\03components.t poch.t t\05set.t t\05tz.t t\06add.t t\07compare.t t\09greg.t t\10subtract.t t\11duration.t t\12 t t\13strftime.t t\14language.t t\15jd.t t\16truncate.t t\17set_return.t t\18today.t t\19leap_s .t t\20infinite.t t\21bad_params.t t\zz_00load.t t\zz_01sanity.t t\zz_02last_day.t t\zz_03compo .t t\zz_04epoch.t t\zz_05set.t t\zz_05tz.t t\zz_06add.t t\zz_07compare.t t\zz_09greg.t t\zz_10s ct.t t\zz_11duration.t t\zz_12week.t t\zz_13strftime.t t\zz_14language.t t\zz_15jd.t t\zz_16tru .t t\zz_17set_return.t t\zz_18today.t t\zz_19leap_second.t t\zz_20infinite.t t\zz_21bad_params. Using G:/modules/DateTime.pm/blib t\00load..ok t\01sanityok t\02last_day..ok t\03componentsok t\04epoch.NOK 25# Failed test (t\04epoch.t at line 96) # got: undef # expected: '-2082844800' The 'day' parameter to DateTime::new was an 'undef', which is not one of the allowed types: sca at t\04epoch.t line 101 # Looks like you planned 28 tests but only ran 25. # Looks like your test died just after 25. t\04epoch.dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 25-28 Failed 4/28 tests, 85.71% okay t\05set...ok t\05tzok t\06add...ok t\07compare...ok t\09greg..ok 34/35# this may take a minute... t\09greg..ok t\10subtract..ok t\11duration..ok t\12week..ok t\13strftime..ok t\14language..ok t\15jdok t\16truncate..ok t\17set_returnok t\18today.ok t\19leap_second...ok t\20infinite..NOK 12# Failed test (t\20infinite.t at line 55) # got: '1.#QNAN' # expected: '-1.#IND' t\20infinite..NOK 13# Failed test (t\20infinite.t at line 55) # got: '1.#QNAN' # expected: '-1.#IND' t\20infinite..NOK 14# Failed test (t\20infinite.t at line 55) # got: '0' # expected: '-1.#IND' t\20infinite..ok 36/36# Looks like you failed 3 tests of 36. t\20infinite..dubious Test returned status 3 (wstat 768, 0x300) DIED. FAILED tests 12-14 Failed 3/36 tests, 91.67% okay t\21bad_paramsok t\zz_00load...ok t\zz_01sanity.ok t\zz_02last_day...ok t\zz_03components.ok t\zz_04epoch..NOK 25# Failed test (t\zz_04epoch.t at line 100) # got: undef # expected: '-2082844800' The 'day' parameter to DateTime::new was an 'undef', which is not one of the allowed types: sca at t\zz_04epoch.t line 105 # Looks like you planned 28 tests but only ran 25. # Looks like your test died just after 25. t\zz_04epoch..dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 25-28 Failed 4/28 tests, 85.71% okay t\zz_05setok t\zz_05tz.ok t\zz_06addok t\zz_07compareok t\zz_09greg...ok 34/35# this may take a minute... t\zz_09greg...ok t\zz_10subtract...ok t\zz_11duration...ok t\zz_12week...ok t\zz_13strftime...ok t\zz_14language...ok t\zz_15jd.ok t\zz_16truncate...ok t\zz_17set_return.ok t\zz_18today..ok t\zz_19leap_secondok t\zz_20infinite...NOK 12# Failed test (t\zz_20infinite.t at line 59) # got: '1.#QNAN' # expected: '-1.#IND' t\zz_20infinite...NOK 13# Failed test (t\zz_20infinite.t at line 59) # got: '1.#QNAN' # expected: '-1.#IND' t\zz_20infinite...NOK 14# Failed test (t\zz_20infinite.t at line 59) # got: '0' # expected: '-1.#IND' t\zz_20infinite...ok 36/36# Looks like you failed 3 tests of 36. t\zz_20infinite...dubious Test returned status 3 (wstat 768, 0x300) DIED. FAILED tests 12-14 Failed 3/36 tests, 91.67% okay t\zz_21bad_params.ok Failed Test Stat Wstat Total Fail Failed List of Failed --- t\04epoch.t255 65280284 14.29% 25-28 t\20infinite.t 3 768363 8.33% 12-14 t\zz_04epoch.t 255 65280284 14.29% 25-28 t\zz_20infinite.t3
Re: Rough first draft of a FAQ
On Fri, May 30, 2003 at 12:36:17PM -0500, Dave Rolsky wrote: The archives are linked on the mailing list page and the modules page has links to each module's CPAN page. OK. At the very least I want to leave a link to the top of datetime.perl.org in case they came in using a link fron elsewhere (e.g. google). I will probably leave the tip for how to search the archives with google unless you are strongly opposed. How do you want to progress from here... I will try and get the TODO items cleaned up and have a look at the grouping and ordering. At some point I should get CVS access and commit the stuff. -ben
RE: Bug in DateTime::Span-contains()
Hi Dave, On Fri, 30 May 2003, Hill, Ronald wrote: t\04epoch.NOK 25# Failed test (t\04epoch.t at line 96) # got: undef # expected: '-2082844800' The 'day' parameter to DateTime::new was an 'undef', which is not one of the allowed types: sca at t\04epoch.t line 101 # Looks like you planned 28 tests but only ran 25. # Looks like your test died just after 25. t\04epoch.dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 25-28 Failed 4/28 tests, 85.71% okay What version of Perl do you have installed? I bet this is because you're using an earlier version of Time::Local, because I have problems with these tests using Perl 5.00503 on my Linux box. I did this test using activestate 5.6.1 So I switched to 5.8.0 and reran the tests. results: t\zz_03components.ok t\zz_04epoch..ok 25/28The 'hour' parameter to DateTime::new was an 'und of the allowed types: scalar at t\zz_04epoch.t line 105 # Looks like you planned 28 tests but only ran 25. # Looks like your test died just after 25. t\zz_04epoch..dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 26-28 Failed 3/28 tests, 89.29% okay Now it does not like the hour parameter!! [snipped] This is just weird. Why does Windows think that infinity - infinity = 0 for the third subtraction, but not the first two? I'm so confused. For these tests the results were the same!! I am confused as well :( I wish I could help out more!! Ron Hill
Re: installing DateTime-TimeZone-0.17 on HPUX 10.20 perl 5.8.0 using HP's ANSI C Compiler?
On Fri, 30 May 2003, Hill, Ronald wrote: Hi All, Has anyone installed DateTime-TimeZone-0.17 on HPUX? make is reporting line to long. $ /app/perl5.8.0/bin/perl Makefile.PL Writing Makefile for DateTime::TimeZone $ make Make: line too long. Stop. $ which make /bin/make $ ls -l /bin/make lr-xr-xr-t 1 root sys 17 Nov 1 1999 /bin/make - /usr/ccs/bin/make I have checked the Makefile.PL file for those ^M char and found none. Does anyone have any ideas? This might be fixed by upgrading ExtUtils::MakeMaker to a newer version. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Rough first draft of a FAQ
* Ben Bennett [EMAIL PROTECTED] shaped the electrons to say... I have a (very) rough draft of a faq available at: http://www.limey.net/~fiji/perl/ Ben - I like the FAQ a lot. A suggestion though - you offer quite a few functions that do useful things, ie: get_day_in_same_week, etc. It'd be useful (to me at least) if those made it into a DateTime::Helpers or somesuch. -D -- I'm riding my bicycle 600 miles to fight AIDS! I've raised $1850 out of a minimum $2500 so far! Sponsor me at: http://electricrain.com/daniel/lifecycle/sponsor/
Re: Rough first draft of a FAQ
On Fri, 30 May 2003, Dan Sully wrote: * Ben Bennett [EMAIL PROTECTED] shaped the electrons to say... I have a (very) rough draft of a faq available at: http://www.limey.net/~fiji/perl/ Ben - I like the FAQ a lot. A suggestion though - you offer quite a few functions that do useful things, ie: get_day_in_same_week, etc. It'd be useful (to me at least) if those made it into a DateTime::Helpers or somesuch. Or maybe just into the core. I'm open to adding more methods, as long as they provide something useful that people would otherwise end up re-implementing in their own code. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Rough first draft of a FAQ
Dave Rolsky wrote: Or maybe just into the core. I'm open to adding more methods, as long as they provide something useful that people would otherwise end up re-implementing in their own code. I use something like 'truncate( to = sunday )' inside DT::E::Recurrence. Does it make sense for somebody else? - Flavio S. Glock
Re: Rough first draft of a FAQ
I would not be opposed, but I think we should let the FAQ settle a bit before rolling stuff into the core. Some of the items are really the DT::Business that Dave mentioned earlier. Perhaps others belong in DT itself or in DT::Calc. One reason that I sort of think the latter is that you want to be able to define what a week is. You may be using the ISO week (which may be in a different year) or a different start day for the week (e.g. Saudi Arabia has the weekend on Friday and Saturday, I dunno if that is common in other Islamic countries). So you need a way to set that calculation wide, so you may need to do something like: use DT::Calc qw(:constants); my $calc = DT::Calc-new(week_starts_with = MONDAY); $calc-get_day_in_same_week($dt, THURSDAY); or somesuch. The sub names are pretty ugly so I am open to suggestions for better ones. -ben On Fri, May 30, 2003 at 01:46:57PM -0500, Dave Rolsky wrote: On Fri, 30 May 2003, Dan Sully wrote: * Ben Bennett [EMAIL PROTECTED] shaped the electrons to say... I have a (very) rough draft of a faq available at: http://www.limey.net/~fiji/perl/ Ben - I like the FAQ a lot. A suggestion though - you offer quite a few functions that do useful things, ie: get_day_in_same_week, etc. It'd be useful (to me at least) if those made it into a DateTime::Helpers or somesuch. Or maybe just into the core. I'm open to adding more methods, as long as they provide something useful that people would otherwise end up re-implementing in their own code. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
RE: installing DateTime-TimeZone-0.17 on HPUX 10.20 perl 5.8.0 us ing HP's ANSI C Compiler?
On Fri, 30 May 2003, Hill, Ronald wrote: Hi All, Has anyone installed DateTime-TimeZone-0.17 on HPUX? make is reporting line to long. $ /app/perl5.8.0/bin/perl Makefile.PL Writing Makefile for DateTime::TimeZone $ make Make: line too long. Stop. This might be fixed by upgrading ExtUtils::MakeMaker to a newer version. I have upgraded MakeMaker to the current version still fails with line to long :( Ron
RE: installing DateTime-TimeZone-0.17 on HPUX 10.20 perl 5.8.0 us ing HP's ANSI C Compiler?
On Fri, 30 May 2003, Hill, Ronald wrote: Has anyone installed DateTime-TimeZone-0.17 on HPUX? make is reporting line to long. $ /app/perl5.8.0/bin/perl Makefile.PL Writing Makefile for DateTime::TimeZone $ make Make: line too long. Stop. This might be fixed by upgrading ExtUtils::MakeMaker to a newer version. I have upgraded MakeMaker to the current version still fails with line to long :( I doubt ther's much I can do about it, since I don't think changing the module names just for this is a good idea. Presumably, the long module name plus your path is too long. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
