DateTime::Format::Pg move to github
Hi I just got a patch for DateTime::Format::Pg this morning, and looks like I have no access to my old sourceforge account (they had a password reset earlier this year, apparently?), and I couldn't retrieve my account information via their password reset thingie even after trying all email addresses that I have now. Given this I think I'd like to move DateTime::Format::Pg to github. I don't think anybody is going to be affected by this, but just wanted to check/announce with you folks here. Holler if this for some reason affects you. --d
test failure
Just sending to the list, in case people didn't notice: https://rt.cpan.org/Public/Bug/Display.html?id=62061 --d
Re: DateTime::Format::W3CDTF bug
Doh -- I'd forgotten this myself. What's your PAUSE ID? --d 2010/9/27 Gregory Williams g...@evilfunhouse.com: On Sep 26, 2010, at 3:47 PM, Dave Rolsky wrote: Doh, apparently I only have comaint. Daisuke Maki has primary, it seems. Daisuke, can you give Gregory comaint? Do you want me to completely take over ownership of the module or is there a way I should be looking to work with the existing DateTime svn? thanks, .greg
Re: DateTime and bigint - we got a problem
Parameter validation is also one of the bottlenecks when it comes to using DateTime. I personally don't believe that removing Params::Validate would make an application run faster, but at least I could silence some of the nagging that I get when I recommend DateTime to others. Would it be worthwhile to create a P::V free version of datetime in the repo and see what it gets up? --d 2010/9/8 Michael G Schwern schw...@pobox.com: On 2010.9.7 8:33 AM, Maxim Yemelyanov wrote: i'm writing concerning an annoying feature of DateTime - parameters validation. with use bigint in effect, DateTime croaks because ints are no longer scalars, but rather hashrefs. the module uses Params::Validate and expects most of its arguments to be of type SCALAR. i guess it makes sence to either allow the to also be OBJECTS, or, more precisely, its refs to equal 'bigint'. can someone fix this or i'd better send a patch? If you want to take it to the next level, Params::Validate generally ignores the idea of overloading. Part of the point of overloading is to fool interfaces into accepting objects, so it defeats the point if you have something that goes around blowing their cover. I'd say that SCALAR should quietly accept a string or numeric overloaded object. You can detect numeric overloading by checking overload::Method($obj, q[0+]). String with q[]. Since Params::Validate doesn't distinguish between strings and numbers, you'd have SCALAR check for either. Like: blessed($thing) (overload::Method($thing, q[0+]) || overload::Method($thing, q[])); For bonus points, do ARRAYREF, HASHREF and BOOLEAN. -- A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email?
Re: datetime::duration doesn't do what I expect and doesn't produce an error either
If $date1 and $date2 contain specific dates and times. Then the conversion to $duration = ($date1-$date) has chosen to lose the information I was seeking during the instantiation. It was possibly to know the number of seconds (without ambiguity) before the internal representation was chosen. No, it didn't lose anything. You are only looking for an illusion there. Our concept of a constant 24 hour, 1440 minute, 86400 second day is simply a lie to make our daily routines easier. We are actually constantly introduced with 86401 second days, 25 hour days and 23 hour days. DateTime correctly computes those as well, and DT::Duration is the way it is because of this. But yes, that's not terribly well documented. (I personally wouldn't have really grasped it until I dived into the code to write my own calendar module) --d
Re: ANNOUNCE: DateTime::Format::W3CDTF
I'll take it. (and I won't make it Moose, as I believe there are people who do not want Moose in their dependency chain) --d 2009/11/2 Dave Rolsky auta...@urth.org: If someone else wants to maintain this module please let me know. I don't want it ;) 0.05 2009-11-01 - Fixed a long-standing bug where a time zone other than UTC that had an offset of 0 caused the format_datetime method to return the string 0. RT #22802. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: Class::DBI::Plugin::DateTime requires DBD::Pg?
I didn't even know where that sourcecode was, so pulled it up from CPAN, stuck it into a new repository, and now you have 0.05. Nothing new, just that Makefile.PL assumes you know what you're doing, and won't try to install anything. tests all merrily go their own way unless the DSNs and what not are explicitly provided. --d Rick Measham wrote: G'day Daisuke (or anyone else helping maintain the module ..), We've just installed your Class::DBI::Plugin::DateTime module. We're using it for mySQL, but it requires us to install Postgres modules. Any chance you can remove them from the required libs and only run the tests if they're installed? DBD::Pg DateTime::Format::Pg Cheers! Rick Measham
Re: Class::DBI::Plugin::DateTime requires DBD::Pg?
Boy, I don't even remember when/why/what that module is... It must be one of my first ever CPAN modules. I'm going to have to dig for the source, so please give me some time. thanks for the heads up --d Rick Measham wrote: G'day Daisuke (or anyone else helping maintain the module ..), We've just installed your Class::DBI::Plugin::DateTime module. We're using it for mySQL, but it requires us to install Postgres modules. Any chance you can remove them from the required libs and only run the tests if they're installed? DBD::Pg DateTime::Format::Pg Cheers! Rick Measham
Re: DateTime::Lite
sure thing. as an aside, it's very unlikely I'll finish this up this year... too busy trying to startup a Perl oraganization here in Japan /and/ writing a book... --d Dave Rolsky wrote: On Sat, 22 Nov 2008, Daisuke Maki wrote: I have an RFC/request for blessing for a module. So my thought is go ahead, but can you call it DateTimeX::Lite? Basically, I'm worried that people will expect your module to work just like DateTime, but since they won't share a common code base going forward, that may not be the case. /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: epoch() bug with v0.45
Are you sure this is what you intended to do? (from r4116)
-sub quarter {$_[0]-{local_c}{quarter} };
-
--d
Dave Rolsky wrote:
On Mon, 24 Nov 2008, Avianna Chao wrote:
I've been using DateTime 0.41 quite happily for a while, but recently
I upgraded to 0.45, and am encountering a bug where if you do a
epoch() on a DT object that is quite sometime before epoch.
Fixed in 0.4501.
-dave
/*
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
*/
Re: epoch() bug with v0.45
that was my experiment repo. false alarm, sorry.
I really ought to stop checking emails and coding in the morning.
--d
Dave Rolsky wrote:
On Wed, 26 Nov 2008, Daisuke Maki wrote:
Are you sure this is what you intended to do? (from r4116)
-sub quarter {$_[0]-{local_c}{quarter} };
-
I'm not sure what you're looking at. It's not in my diff, and the
method's still there (the tests would catch it if not).
-dave
/*
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
*/
Re: DateTime::Lite
A lot of times you don't even need to do date time arithmetic, for example. These methods are separated out onto a different file, so you need to load it on demand. use DateTime::Lite qw(Arithmetic); use DateTime::Lite qw(Strftime); Have you actually benchmarked the memory usage and compile speed for this stuff? I have a hard time imagining it really is all that slow, since it amounts to a few methods in each case. Yes, I wrote a crude benchmark script in DateTime-Lite/tools/benchmar/load_times.pl If you don't load arithmetic and strftime, DT::Lite is twice as fast plain DT. Rate dt dt_lite_full dt_lite dt 46.6/s -- -13% -49% dt_lite_full 53.7/s 15% -- -41% dt_lite 91.7/s 97% 71% -- And again, /I know/ this isn't that much of a practical problem, because the engineer's correct answer is if the load time is slow, load it once, and use some sort of persistent environment. This is mainly a marketing issue to my audience, who, for example, includes CGI developers (i.e., persistent environment isn't an option). BTW, dt_lite_full is almost equivalent to using DateTime.pm, but I /think/ the difference comes from the tweak I did to switch method calls to function calls. That can probably be tweaked in DateTime.pm, if you want me to apply it. Singletons are okay, they serve a particular purpose. But besides being a memory hog of relative low benefit, when given the number of time zones are locales, they are just way too overwhelming for underlings. Could you explain this? What are you doing instead of singletons? Do you reload the time zone every time it's asked for? Also, that second sentence makes no sense ;) No, it's cached in memory, so in that sense they are singletons. However, they are all instances of the same DT::Lite::TimeZone object. When asked to load a time zone, I'm just require()ing a plain perl file, and shoving them to the constructor of DT::Lite::TimeZone. The timezone created is stored in a hash. Creating GVs for each timezone is a waste. Creating one class, then creating instances for each timezones are much cheaper. I discussed this briefly when I was trying to do DateTime::TimeZone::XS, but I got warnocked. With this version, the objects are mostly the just plain objects, and the exact definition for each timezone/locale is stored in data files. What do the data files look like? If using them is faster than the current DT::TZ implementation, is there any reason we can't switch DT::TZ to use it? I don't think DT::TZ will benefit anything from using my method, as they are true singletons. the data format isn't going to change anything. I'm not saying DT::TZ needs to change, either. If you want singletons that's just fine, but one of my requirements is to reduce the number of classes that needs to be installed. Again, /I know/ that installing data files instead of classes isn't any better, but I'd like to have a way to pick and choose which time zones the user wants to use/install, so they have the illusion of control over how much stuff is required to run DT::Lite. --d
Re: DateTime::Lite
Isn't this just a test of load times? How could using methods vs functions make any difference to a module's load times? ah, well, um, I was still waking up when I wrote the email? Yes, it makes sense that not creating all those namespaces would reduce memory usage. I'm a little leary of changing things now, since it'd be backwards incompatible. I wonder if anyone actually relies on those objects having a namespace that includes the time zone though. As a programmer I'd say to hell with wasted memory, but as a product manager, I'd say keep it in the current state until you come up with a major upgrade (version 1.00, or something). At this point I'd rather see DateTime as a possibly heavy, but reliable reference point than to have its interface changed, so I can safely recommend DateTime.pm to anybody, while sneaking things like DT::Lite as a quick hack. --d
Re: DateTime::Lite
I didn't notice so I didn't write this, but though Time::Piece may be in core, it's not in 5.8.x corelist -a Time::Piece 5.009005 1.11_02 5.01 1.12 If the argument there was Time::Piece has /always/ been in core, I would concede, but since it's only in the latest release, that would defeat my purposes as well. I doubt if I am the only person who might ask this question. Perhaps you should add a comparison to Time::Piece to the POD? Well, not that I'm trying to be terse... but I need DateTime, not Time::Piece. I need something that resembles DateTime, but faster, leaner, without XS. Time::Piece just wouldn't cut it. Since XS rules out Time::Piece, I still don't see why /not/? Is there any reason why? --d
Re: DateTime::Lite
Lite may pass the set of tests you extracted, but what about compatability with DateTime extensions like ::Set? I contend that the best way to tackle something like this and yield a more broadly useful Lite kit would be to get DateTime to use AutoSplit and/or subclass DateTime to override the chubbier bits. In my usage of DateTime, loading has never been the issue, but rather things like parameter validation and lack of memoization (friendliness). um, wait wait. Okay, so I don't want, nor intend to claim Datetime::Lite to be 100% API compatible with DateTime. I don't intend for DateTime::*** modules to use DateTime::Lite. This is for people who use the minimal aspects of DateTime, which is mainly to grab a date, do some calculation, and maybe print them out. But at the same time, I don't want Time::Piece (even if it was pure perl), but something that resembles DateTime, because 1. I want something that can (relatively) easily be replaced back to DateTime later. 2. I want something that is as full-featured as DateTime, so my audience don't start saying things like Well, using modules give you performance penalty, so let's /not/ use them at all! or Perl sucks, let's use because of petty performance problems. okay, so I'm starting to suspect that I didn't define my audience, and that's causing people to go WTF, another bad clone?. Perhaps that's what's Jaldhar is asking elsewhere in this thread. --d
Re: DateTime::Lite
Now that you have explained it I don't see why not either. However personally I have always thought of Time::Piece as DateTime 'lite' and I am guessing other people might too. So I think an explicit comparison in the docs would be useful. Thank you. I think I'm starting to see what was missing from my mission statement (or the lack thereof) --d
Re: DateTime::Lite
http://users.endeworks.jp/~daisuke/DateTime-Lite-0.1.tar.gz As noted before, the timezone/locale stuff are not fully portable yet, so you need to be in the distro's root directory for DateTime::Lite to be usable. --d Yitzchak Scott-Thoennes wrote: On Sat, November 22, 2008 2:26 am, Daisuke Maki wrote: oops, forgot the SVN url http://svn.coderepos.org/share/lang/perl/DateTime-Lite/trunk Could we have a working tarball, please? I gave up after a very brief attempt to install and use Module::Install.
DateTime::Lite
Hi, I have an RFC/request for blessing for a module. So I have this requirement to make DateTime leaner, in terms of speed, load time, and the amount of memory consumed. The target is for casual users, so the use of XS code is not an option either. I've done my share of hacking DateTime before, and I believe that changing the DateTime.pm code base itself is not really an option since DateTime needs to be backward compatible and what not. Instead I took the approach of using DateTime.pm as a reference implementation, and rearranged the code somewhat to get the desired effect. Now I have something that passes all current DateTime tests and named it DateTime::Lite. I intend to do some more hacking soon ish, but thought I'd ask for your comments before hand. I've pasted the current POD for DateTime::Lite at the end of this email. Also, if you are interested, the code is at note that the location of time zones and locales are hard coded now, so DateTime::Lite will only work from the checked out root. regards, --d =head1 NAMEDateTime::Lite - A Low Calorie DateTime =head1 SYNOPSIS use DateTime::Lite; my $dt = DateTime::Lite-new(year = 2008, month = 12, day = 1); $dt-year; $dt-month; $dt-day; $dt-hour; $dt-minuute; $dt-second; # Arithmetic doesn't come with DateTime::Lite by default use DateTime::Lite qw(Arithmetic); $dt-add( DateTime::Lite::Duration-new(days = 5) ); =head1 DESCRIPTION This is a complete rip-off of the great DateTime module. The author simply copy and pasted about 90% of the code, tweaked it and repackaged it. All credits go t o the original DateTime.pm's authors.However, this module was conceived out of a few specific desires : (1) Target those who do not need the full feature of DateTime.pm (2) Get better performance: * Reduce the amount of memory consumed, and * Reduce the time it takes to load the module (3) Make it easy to install on rental servers (4) Bundle everything in one distribution, including timezones and locales To achieve this, we've taken the original DateTime and rearranged it as follows: =over 4 =item DateTime::Lite is Pure Perl No XS, pronto. Since we expect the audience to be people who are not sysadmins, we don't expect them to have a full compiler support either.=item Parameter validation is done by hand =item Parameter validation is done by hand Params::Validate is a great module, but it slows things down. We don't see the merit of removing it from the original DateTime.pm, but we did so in this version. =item Non-essential methods are loaded on demand A lot of times you don't even need to do date time arithmetic, for example. These methods are separated out onto a different file, so you need to load it on demand. use DateTime::Lite qw(Arithmetic); use DateTime::Lite qw(Strftime); =item DateTime::Lite::TimeZone and DateTime::Lite::Locale DateTime::Lite::TimeZone and DateTime::Lite::Locale have big changes from their original counterparts. First, you do NOT call new() on these objects (unless this is something you explicitly want to do). Instead, you need to call load(). So if you were mucking with DateTime::Lite::TimeZone and DateTime::Locale, you need to find out every occurance of DateTime::Lite::TimeZone-load( name = 'Asia/Tokyo' ); and change them to DateTime::Lite::TimeZone-load( name = 'Asia/Tokyo' ); Singletons are okay, they serve a particular purpose. But besides being a memory hog of relative low benefit, when given the number of time zones are locales, they are just way too overwhelming for underlings. With this version, the objects are mostly the just plain objects, and the exact definition for each timezone/locale is stored in data files. # TODO: They can be located anywhere DateTime::Lite can find them TODO: We want to make it easy to pick and choose which locales/timezones to be available -- DateTime::TimeZone and Locale comes with the full-set, and normally we don't need this feature. For example, I only use Asia/Tokyo and UTC time zones for my dayjob. When we ask casual users to install a datetime package, we do not want to overwhelm then with 100+ timezones and locales. =cut
Re: I'd tell you how long it'll take for my hair to fall out but I'm struggling with duration!
this seems to do what you wanted? my $dt1 = DateTime-new( year = 2008, month = 10, day= 2, ); my $dt2 = DateTime-new( year = 2008, month = 10, day= 5, ); my $diff = $dt2 - $dt1; print $diff-delta_days, \n; --d Kristian Flint wrote: Hi everybody! You may remember me from a while back wanting to make a module pertaining to UK bank holidays. I got a bit stuck on some other work and have finally had some time to come back to it. I'm pleased to say that it's going very well but I've hit a small snag, which I could fix with a hack but part of doing all this is wanting to contribute back to the community so I'd rather try and work out why something isn't working... So here's the problem, I've got two DateTime objects and I want to work out how many days there are between them. Simple I thought: my $dt1 = DateTime-new( year = 2008, month = 10, day= 2, ); my $dt2 = DateTime-new( year = 2008, month = 10, day= 5, ); my $span = DateTime::Span-from_datetimes( start = $dt1, end = $dt2 ); my $d = $span-duration; print $d-days; That didn't work so I went back to the documentation and spotted that The last example demonstrates that there will not be any conversion between units which don't have a fixed conversion rate. Which if someone could clarify would be great because the $span-duration seems to return a duration object in seconds, there's definitely a fixed number of seconds in a day (actually unless we're talking about that tiny fraction that ends up counting towards a quarter of a day per year?). Anyways, I thought fair enough, I read on and got to: If you need more flexibility in presenting information about durations, please take a look a DateTime::Format::Duration. Great, nearly there. Except this doesn't seem to be working : ( Can somebody just check I'm not mental: FROM DOCS: http://search.cpan.org/~rickm/DateTime-Format-Duration-1.03a/lib/DateTim e/Format/Duration.pm $d = DateTime::Format::Duration-new( pattern = '%Y years, %m months, %e days, '. '%H hours, %M minutes, %S seconds' ); print $d-format_duration( DateTime::Duration-new( years = 3, months = 5, days= 1, hours = 6, minutes = 15, seconds = 45, nanoseconds = 12000 ) ); # 3 years, 5 months, 1 days, 6 hours, 15 minutes, 45 seconds END FROM DOCS This doesn't actually return what's stated above (#) but actually returns 0 years, 41 months, 1 days, 00 hours, 375 minutes, 45 seconds And if I try and make the pattern = '%e' to just get the number of days, this returns 0! Have I missed something?! I'm thinking there's probably a _much_ easier way of getting what I want and it's just passed by my small boy brain. Appreciative of any help, Kristian
Re: DateTime From Solar Longitude
Sorry, that module is a bit unmaintained. If you find any insconsistencies, let me know. # those were my first CPAN modules *blush* --d Jaldhar H. Vyas wrote: On Sun, 22 Jun 2008, Flavio S. Glock wrote: how about: use DateTime::Event::Lunar; use DateTime::Event::SolarTerm; my $new_moon = DateTime::Event::Lunar-new_moon(); my $dt0 = DateTime-today; my $eq = DateTime::Event::SolarTerm-next_term_at( datetime = $dt0, longitude = 0, ); print $new_moon-next( $eq ), \n; Thanks, this is working great with my test data. Though DateTime::Event::Solarterm is failing a bunch of its tests with is a bit worrisome.
Re: DateTime-season?
David,
for some reason I *knew* you would be trying SolarTerm...
Of course apparently the test failed for you (which seem to pass on my
laptop, by the way), but anyhow.
I was actually going to reply to this thread, but then I realized that
DT::Event::SolarTerm isn't really worth it because of the astronomical
calculations that it depends on. It takes time to generate the solar
terms, and they are pretty far off from the dates you described in your
email.
For example, Winter in terms of solar terms is circa late October to
late January. April follows it up to sometime in April. April to early
August is summer and the rest until sometime in late September / early
October.
In other words, it varies from year to year, and it's really tied to the
location of the Sun.
For editorial purposes, you probably want something more fixed.
--d
David E. Wheeler wrote:
Hey All,
Someone on the Bricolage list needed a season method, so I whipped up
this ugly one:
sub season {
my $date = shift-strftime('%m-%d');
return $date lt '03-21' ? 'winter'
: $date lt '06-21' ? 'spring'
: $date lt '09-21' ? 'summer'
: $date lt '12-21' ? 'autumn'
:'winter';
}
Since seasons can sometimes change on the 22nd instead of the 21st, this
isn't quite right. Anyone else done something like this but more accurate?
Best,
David
Re: Template::Stash + DateTime overloading
Smells like a TT problem.
The line in question at Template::Stash is reads:
my $atroot = ($root eq $self);
This logic exists so such that TT knows if it's looking at the implicit
stash context, or a child element in the stash.
The same logic, if I'm not mistaken, in the XS version reads:
atroot = sv_derived_from(root, TT_STASH_PKG);
So if I change line 685 of Stash.pm to
my $atroot = eval { $root-isa(__PACKAGE__) };
Voila!
[EMAIL PROTECTED] daisuke$ perl test.pl
# DateTime 0.34
# Template 2.15
ok 1 - ok
ok 2 - ok
1..2
--d
Tatsuhiko Miyagawa wrote:
Hi,
Passing DateTime object to TT (Template Toolkit) without Stash::XS
built, DateTime overloading gives you an annoying error like
following. (See DATA section for the result on my box.)
Is it something fixable on the user's end, or simply the bug of
DateTime, or TT?
#!/usr/bin/perl
use strict;
use warnings;
use DateTime;
use Template;
use Template::Stash;
use Template::Stash::XS;
use Test::More 'no_plan';
diag DateTime $DateTime::VERSION;
diag Template $Template::VERSION;
my $tmpl = TMPL;
today is [% date.ymd %]
TMPL
for my $stash ( Template::Stash-new, Template::Stash::XS-new ) {
my $tt = Template-new({ STASH = $stash });
ok( $tt-process(\$tmpl, { date = DateTime-now }, \my $out),
$tt-error || ok);
}
__END__
# DateTime 0.30
# Template 2.14
not ok 1 - undef error - Cannot compare a datetime to a regular scalar
at /usr/local/lib/perl/5.8.4/DateTime.pm line 1435.
#
# Failed test 'undef error - Cannot compare a datetime to a regular
scalar at /usr/local/lib/perl/5.8.4/DateTime.pm line 1435.
# '
# in /home/miyagawa/tmp/tt-datetime.pl at line 19.
ok 2 - ok
1..2
# Looks like you failed 1 test of 2.
Re: Calculate days left in month
my $today = DateTime-today;
my $last = DateTime-last_day_of_month(
year = $today-year,
month = $today-month
);
my $diff = $last - $today;
# using DateTime::Format::Duration
my $fmt = DateTime::Format:::Duration-new(
pattern = %j days left
);
print $fmt-format_duration($diff), \n
# since this is within the same month, you could
# use in_units as well
print $diff-in_units('days'), days left\n;
--d
Jay wrote:
How do I calculate the number of days left in the month?
The best I could do was something like this, which doesn't really work:
my $now = DateTime-now();
my $first_of_this_month = DateTime-new(
month = $now-month(),
day = 1,
year= $now-year(),
);
my $one_month = DateTime::Duration-new( months = 1 );
my $one_day = DateTime::Duration-new( days = 1 );
my $last_day_of_this_month = $first_of_this_month + $one_month - $one_day;
my $d = DateTime::Format::Duration-new( pattern = '%e days left in
this month' );
print $d-format_duration( $now - $last_day_of_this_month ), \n;
Thanks,
Jay
DateTime::TimeZone performance
I've done some more tuning for DateTime-TimeZone, and believe that I've
cut down most of the bottlenecks from DT::TZ (and it should work for
those without XS)
I based most of my profiling and performance measurements on t/02basic.t
from DateTime::TimeZone distro, and here's the summary of improvements:
- Using XS, as well as staying away from Singleton patterns
saves us about 5% memory usage, which turns out to be somewhere
around 6MB to 7MB when all zones are loaded.
- Using my already-installed version of DateTime::TimeZone (the
version from CPAN) against the optimized version, I see that
the tuned version runs t/02basic.t about 30-40seconds faster.
...And here are my random findings:
- I have to admit, while XS-fying the DateTime::TimeZone has
its merits, it's a fine line between the choice to go
with either PurePerl or XS DT::TZ, because it doesn't
improve things *that* much.
At least a straight port doesn't buy you much. If we are to
expect perfomance gains from DT::TZ side, we'd have
to rethink of the way timezone logic is handled.
However, even if we decide not to go the XS route, I strongly
suggest that the following be made:
* stay away from singletons
* incorporate my fixes to reduce date-math (see below)
- Date math is terribly slow. Most of performance improvements
from DT::TZ came from reducing the number of calls to
DateTime::add_duration(). For example,
my $diff = $dow - $dt-day_of_week;
$dt-add(days = $diff);
is definitely faster than
while ($dt-day_of_week != $dow) {
$dt-add(days = 1);
}
That also means that if we can somehow speed up DT::add_duration(),
then overall perfomance will improve significantly
- Just as a reference, here's Devel::DProf output of running
t/02basic.t against DateTime-TimeZone-XS:
Total Elapsed Time = 92.19635 Seconds
User+System Time = 42.84635 Seconds
Exclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c Name
54.5 23.38 25.874 248526 0.0001 0.0001 Params::Validate::_validate
17.5 7.518 11.644 51285 0.0001 0.0002 DateTime::Duration::new
16.6 7.113 27.149 63321 0.0001 0.0004 DateTime::new
8.73 3.742 6.443 64095 0.0001 0.0001 DateTime::TimeZone::new
8.71 3.733 61.506 35208 0.0001 0.0017 DateTime::add_duration
7.06 3.025 23.092 34867 0.0001 0.0007 DateTime::from_object
5.15 2.207 22.768 13760 0.0002 0.0017
DateTime::TimeZone::OlsonDB::utc_d
atetime_for_time_spec
4.81 2.061 2.116 35215 0.0001 0.0001 Params::Validate::_validate_pos
4.56 1.952 2.217 64470 0. 0.
DateTime::_calc_local_components
3.98 1.707 3.700 13299 0.0001 0.0003
DateTime::TimeZone::OlsonDB::Chang
e::new
2.26 0.970 0.970 315752 0. 0. DateTime::__ANON__
1.97 0.843 0.843 3 0. 0. DateTime::clone
1.90 0.813 23.050 13760 0.0001 0.0017
DateTime::TimeZone::OlsonDB::parse
_day_spec
1.74 0.747 0.572 35251 0. 0. DateTime::set_time_zone
1.48 0.635 4.431 16075 0. 0.0003 DateTime::Duration::inverse
1.30 0.556 4.071 7216 0.0001 0.0006 DateTime::last_day_of_month
1.28 0.549 0.549 34866 0. 0. DateTime::Duration::deltas
1.23 0.526 0.526 61465 0. 0. DateTime::hms
1.16 0.497 60.143 109800 0. 0.0005 DateTime::_calc_utc_rd
1.12 0.482 0.608 61465 0. 0. DateTime::ymd
1.04 0.445 0.445 35208 0. 0. DateTime::Duration::is_zero
My changes are all available on the xs branch:
https://svn.sourceforge.net/svnroot/perl-date-time/modules/DateTime-TimeZone/branches/xs
http://svn.sourceforge.net/viewcvs.cgi/perl-date-time/modules/DateTime-TimeZone/branches/xs/
HTH.
--d
Re: DateTime::TimeZone performance
hmmm, isn't that a bit much? I mean, you can't really expect to memoize
date math.
--d
Dr.Ruud wrote:
Daisuke Maki schreef:
- Date math is terribly slow. Most of performance improvements
from DT::TZ came from reducing the number of calls to
DateTime::add_duration(). For example,
my $diff = $dow - $dt-day_of_week;
$dt-add(days = $diff);
is definitely faster than
while ($dt-day_of_week != $dow) {
$dt-add(days = 1);
}
That also means that if we can somehow speed up DT::add_duration(),
then overall perfomance will improve significantly
Dit you also test with Memoize?
Re: DateTime::TimeZone performance
That depends entirely on your application. If you happen to call a certain sub (or method) often and with the same parameters, it can be worth it. Exactly. It depends on your *application* I'm trying to optimize DateTime::TimeZone itself ;) --d
yet another XS patch
Hi all,
I've been absent for a while, but I decided to take the last couple of
days to retry my efforts to XS-fy various DT components.
As you may recall, my previous attempt was a relatively straight forward
port of the underlying perl code to XS, and to my dismay this resulted
in no detectable change in memory footprint or speed. And so I kind of
gave up.
Much later, I've realized that using Singleton pattern consumes much
more memory than creating many instances of the same class, probably due
to the overhead of allocating a new stash for each new namespace.
So this time around I've changed my strategy, and did the following:
- port stuff to XS
- store each data in a C struct
- but the actual data resides in .pm files that gets
loaded in the C structure on demand.
- stop using singletons.
- means that most of the objects are now blessed to
DateTime::TimeZone, instead of, say,
DateTime::TimeZone::America::Chicago.
This may or may not bite you..
- use a package level %CACHE to store each instance
Because I've already been burnt the last time after spending a lot of
time, this time around I just hacked around code and haven't done any
extensive testing or benchmarking yet.
But anyway, with the attached patch (against latest svn), the tests
pass, and I think I've managed to reduce the memory footprint a bit:
# pure perl (BEFORE LOAD)
RSHRD RSIZE VSIZE
624K 1.51M 27.1M
# pure perl (AFTER LOAD)
RSHRD RSIZE VSIZE
784K 14.7M 39.8M
# XS (BEFORE LOAD)
RSHRD RSIZE VSIZE
832K 2.48M 28.5M
# XS (AFTER LOAD)
RSHRD RSIZE VSIZE
832K 8.96M 34.8M
I'll comeback to doing more extensive testing, but meanwhile if any of
you are willing to run more extensive tests, that would be great.
Regards,
--d
=== Build.PL
==
--- Build.PL(revision 3631)
+++ Build.PL(local)
@@ -3,7 +3,7 @@
use Module::Build;
use File::Spec;
-unless ( -e File::Spec-catfile( qw( lib DateTime TimeZone America Chicago.pm
) ) )
+unless ( -e File::Spec-catfile( qw(src tzone.h) ) ) #qw( lib DateTime
TimeZone America Chicago.pm ) ) )
{
warn 'EOF';
@@ -30,5 +30,6 @@
},
build_requires = { 'Module::Build' = 0 },
sign= 1,
+c_source = 'src',
create_makefile_pl = 'passthrough',
)-create_build_script;
=== lib/DateTime/TimeZone/Floating.pm
==
--- lib/DateTime/TimeZone/Floating.pm (revision 3631)
+++ lib/DateTime/TimeZone/Floating.pm (local)
@@ -1,23 +1,32 @@
package DateTime::TimeZone::Floating;
-
use strict;
-
use vars qw ($VERSION @ISA);
-$VERSION = 0.01;
-
use DateTime::TimeZone;
use base 'DateTime::TimeZone::OffsetOnly';
-sub new
+BEGIN
{
-my $class = shift;
+$VERSION = 0.01;
-return bless { name = 'floating',
- offset = 0 }, $class;
+if (DateTime::TimeZone::LOADED_XS) {
+no strict 'refs';
+*new = sub {
+my $class = shift;
+return $class-xs_init('floating', 0);
+};
+} else {
+no strict 'refs';
+*new = sub {
+my $class = shift;
+bless { name = 'floating', offset = 0 }, $class;
+};
+}
}
sub is_floating { 1 }
+1;
+
__END__
=head1 NAME
=== lib/DateTime/TimeZone/OffsetOnly.pm
==
--- lib/DateTime/TimeZone/OffsetOnly.pm (revision 3631)
+++ lib/DateTime/TimeZone/OffsetOnly.pm (local)
@@ -24,17 +24,26 @@
return DateTime::TimeZone::UTC-new unless $offset;
-my $self = { name = DateTime::TimeZone::offset_as_string( $offset ),
- offset = $offset,
- };
+my $self;
+if (DateTime::TimeZone::LOADED_XS) {
+$self = $class-xs_init(
+DateTime::TimeZone::offset_as_string( $offset ),
+$offset,
+);
+} else {
+$self = bless {
+name = DateTime::TimeZone::offset_as_string( $offset ),
+offset = $offset,
+}, $class;
+}
-return bless $self, $class;
+return $self;
}
sub is_dst_for_datetime { 0 }
-sub offset_for_datetime { $_[0]-{offset} }
-sub offset_for_local_datetime { $_[0]-{offset} }
+sub offset_for_datetime { $_[0]-offset }
+sub offset_for_local_datetime { $_[0]-offset }
sub is_utc { 0 }
=== lib/DateTime/TimeZone/OlsonDB.pm
==
--- lib/DateTime/TimeZone/OlsonDB.pm(revision 3631)
+++ lib/DateTime/TimeZone/OlsonDB.pm(local)
@@ -241,7 +241,7 @@
}
else
{
-die Invalid on spec for rule: $day\n;
+Carp::confess Invalid on spec for rule: $day\n;
}
}
@@ -482,13 +482,14 @@
use strict;
-use DateTime;
+# use DateTime;
use
Re: yet another XS patch
Done. I've done a bit of benchmarking to my previous patch, and found out that it runs a bit slower, so I profiled my code and changed the bits that called $tz-spans() so that it's a bit more efficient. Please also note that there's no PP version of the module yet. --d Dave Rolsky wrote: On Thu, 20 Jul 2006, Daisuke Maki wrote: But anyway, with the attached patch (against latest svn), the tests pass, and I think I've managed to reduce the memory footprint a bit: Can you make a branch in the DateTime SVN repo and check this in? https://svn.sourceforge.net/svnroot/perl-date-time/modules/DateTime-TimeZone/branches/xs -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: XS Leap second questions
Daisuke Maki tried making all the DT::TZ modules use XS, and in fact went so far as to turn them into C-based data structures that were primarily accessed via XS. Strangely, this was also slower and more memory-intensive than the Perl version. My next guess was that this had to do with how Perl allocates memory for each namespace. So I was thinking I could try to make a single object that could represent all the timezones, but I was kind of lost momentum while designing that. sad. Perhaps somebody can think of a way to do something like this? my $tz = DateTime::TimeZone-new( name = ... aliases = ... other_required_fields = ... ); This would mean that we would be creating a single .xs file that has a hash lookup of timezone names to C structs, and we would be initializing the object with that data. --d
Re: Refactoring of Format::Pg-parse_duration()
I've refactored the parse_duration() method of DateTime::Format::Pg so that it's much simpler, and a single Regex supports both ISO and Postgres-default duration formats. I added a whole slew of tests extracted from the PostgreSQL tests, too. Patch attached. applied and committed. I'll release 0.10 shortly. --d
Re: infinite datetimes for DT::F::Pg?
Dave,
I took over the maintainer role for DT::F:Pg.
Want to try out this patch?
I'll release it if it works (I personally don't use infinite datetime on
Pg, so it would be better if you check it out...)
--d
Dave Rolsky wrote:
Is there any particular reason this isn't supported other than lack of
tuits? Pg can return infinity or -infinity for a datetime, so it'd
be nice to turn that into the appropriate DateTime::Infinite object (and
vice versa).
Claus, I can make the changes myself if you'd like.
-dave
/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg. My book blog
===*/
Index: Changes
===
RCS file: /cvsroot/perl-date-time/modules/DateTime-Format-Pg/Changes,v
retrieving revision 1.7
diff -d -u -r1.7 Changes
--- Changes 16 Mar 2005 16:13:18 - 1.7
+++ Changes 1 Sep 2005 23:17:24 -
@@ -1,5 +1,9 @@
Revision history for Perl extension DateTime::Format::Pg.
+0.09 Fri Sep 02 09:00:00 2005
+- support infinite, -infinite for parse_timestamp(tz) and format_datetime,
+ format_timestamp
+
0.08 Wed Mar 16 16:00:00 2005
- fixed parse_time (John Siracusa, bug #8516)
- format_interval was missing (CEESHEK, bug #11898)
Index: lib/DateTime/Format/Pg.pm
===
RCS file:
/cvsroot/perl-date-time/modules/DateTime-Format-Pg/lib/DateTime/Format/Pg.pm,v
retrieving revision 1.13
diff -d -u -r1.13 Pg.pm
--- lib/DateTime/Format/Pg.pm 16 Mar 2005 16:13:18 - 1.13
+++ lib/DateTime/Format/Pg.pm 1 Sep 2005 23:17:25 -
@@ -12,7 +12,7 @@
use DateTime::TimeZone::UTC;
use DateTime::TimeZone::Floating;
-$VERSION = '0.08';
+$VERSION = '0.09';
$VERSION = eval $VERSION;
our @ISA = ('DateTime::Format::Builder');
@@ -145,6 +145,26 @@
return $self-new();
}
+sub _create_infinity
+{
+my $self = shift;
+my %p= @_;
+
+if ($p{sign}) {
+return DateTime::Infinite::Past-new;
+} else {
+return DateTime::Infinite::Future-new;
+}
+}
+
+# infinite datetimes
+my $pg_infinity =
+{
+ regex = qr/^(-)?infinity$/,
+ params = [ qw(sign) ],
+ constructor = \_create_infinity,
+};
+
# Dates (without time zone)
#
# see EncodeDateOnly() in
@@ -356,12 +376,12 @@
parse_timetz = [ $pg_timeonly, ],
parse_timestamptz = [ $pg_datetime_iso, $pg_datetime_pg_eu,
$pg_datetime_pg_us, $pg_datetime_sql,
-$pg_datetime_german, ],
+$pg_datetime_german, $pg_infinity ],
parse_datetime = [ $pg_datetime_iso, $pg_datetime_pg_eu,
$pg_datetime_pg_us, $pg_datetime_sql,
$pg_datetime_german,
$pg_dateonly_iso, $pg_dateonly_german,
-$pg_dateonly_sql, $pg_timeonly, ],
+$pg_dateonly_sql, $pg_timeonly, $pg_infinity],
}
);
@@ -754,7 +774,9 @@
sub format_timestamp
{
my ($self,$dt,%param) = @_;
- if($dt-year()=0) {
+ if($dt-is_infinite) {
+return $dt-isa('DateTime::Infinite::Future') ? 'infinite' : '-infinite';
+ } elsif($dt-year()=0) {
return sprintf('%04d-%02d-%02d %s BC',
1-$dt-year(),
$dt-month(),
@@ -785,7 +807,9 @@
sub format_timestamptz
{
my ($self,$dt,%param) = @_;
- if($dt-year()=0) {
+ if($dt-is_infinite) {
+return $dt-isa('DateTime::Infinite::Future') ? 'infinite' : '-infinite';
+ } elsif($dt-year()=0) {
return sprintf('%04d-%02d-%02d',
1-$dt-year(),
$dt-month(),
Index: t/format_datetime.t
===
RCS file:
/cvsroot/perl-date-time/modules/DateTime-Format-Pg/t/format_datetime.t,v
retrieving revision 1.3
diff -d -u -r1.3 format_datetime.t
--- t/format_datetime.t 20 Jun 2004 08:46:05 - 1.3
+++ t/format_datetime.t 1 Sep 2005 23:17:25 -
@@ -1,5 +1,5 @@
# $Id: format_datetime.t,v 1.3 2004/06/20 08:46:05 cfaerber Exp $
-use Test::More tests = 7;
+use Test::More tests = 11;
use DateTime 0.10;
use DateTime::TimeZone;
use DateTime::Format::Pg 0.02;
@@ -75,3 +75,24 @@
my $dt = DateTime-new( %{$tests{$result}} );
is( DateTime::Format::Pg-format_datetime($dt), $result );
}
+
+is(
+DateTime::Format::Pg-format_datetime(DateTime::Infinite::Future-new),
+'infinite'
+);
+
+is(
+DateTime::Format::Pg-format_timestamp(DateTime::Infinite::Future-new),
+'infinite'
+);
+
+is(
+DateTime::Format::Pg-format_datetime(DateTime::Infinite::Past-new),
+'-infinite'
+);
+
+is(
+DateTime::Format::Pg-format_timestamp(DateTime::Infinite::Past-new),
+'-infinite'
+);
+
Re: Simplifying DateTime
use DateTime::Decorated with = [ 'strftime', # Yes, pull it out of DT and put it in # DT:Format:Strftime and DT:Decorated:Strftime 'strptime', # DT:Decorated:Strptime is an accessor interface to DT:F:Strp 'common', # This will have all the 'ymd', 'mdy', 'dmy', 'hms' accessors ], as = 'DTD'; my $dtd = DTD-now; print $dtd-hms(); # 10:10:23 I actually would rather see an mod_perl-style 'add if requested' style. use DateTime; # load just the basics use DateTime::Format qw(strftime strptime hms); # maybe use DateTime::Format qw(:common) ? my $dt = DateTime-now; print $dtd-hms; At least, I don't much like the idea of having to use a different class name like 'DTD' --d
Re: Simplifying DateTime
I'm cool with that .. I guess then that each Format module that is
'use'd would somehow publish methods to the DateTime Class rather than
an object? I'm not sure how this would be technically done using your
example code ..
Ah, bad naming. I wasn't trying to mix DT::F modules here. How bout this
(adhoc naming for demonstration purposes):
use DateTime; # just the basics
use DateTime::API::Format qw(strptime);
The DT::API::* modules are just collection of methods, which could be as
simple as
# even in DT/API/Format.pm, use package DateTime
package DateTime;
sub strptime { ... }
Nothing fancy :)
--d
Re: questions about DateTime::Locale internal structure
Joshua Hoblitt wrote: On Sun, Jul 24, 2005 at 02:30:54PM +0900, Daisuke Maki wrote: - Is there any reason why the locales are not singletons? None that I can think of. - Can I make them singleton? Locale objects are cached during 'load' so that the same object may be shared between multiple DTs. This cache gets dumped when: a new locale is registered, an alias is added, an alias is removed. So it may very well be a win to make DateTime::Locale objects true singletons but you probably won't notice a difference unless your screwing around with custom locales. You might want to seek Dave's opinion before putting effort into a patch. - Can I make parameters like en_language, en_territory, en_complete_name, et al class variables, and do away with any instance variables? That data needs to be unique per locale object. Not per locale class? The data currently resides in LocaleCatalog.pm, which are then just register()ed at load time. they are used as parameters to the Locale constructor, and I don't see them changing, really. What I'm really thinking here is that we can do away with DataForID and shove everything to each class, so that a locale can initialize itself. --d
Re: Data::Juxtapose 0.01 [Re: patch: DateTime::TimeZone PP redundant structures]
The basic format seems good. I'm not sure about using weak_ref, though -- what if an object or structure falls out of scope, yet there's still a key in the data registry? If another ref comes along whose fingerprint matches that key, does it end up getting replaced with undef ? (I'm kind of sleepy at the moment, so I could be misreading the code). I had a reason why I did that, but I can't seem to come up with a good reason now. Hmm. I suppose it won't hurt to *not* have it, I guess I can just remove it. Also, as originally implemented in the context of DateTime::TimeZone, I was using class structures and class methods. You've moved it into object mode, which is fine, but I'm curious as to how you utilize the shared object. I'm assuming it's a single object in the DT::TZ base class? Yeah, that's what I was planning to do. just hold a class variable that points to a D::J object. --d
Data::Juxtapose 0.01 [Re: patch: DateTime::TimeZone PP redundant structures]
Here's the repackaged Data-Juxtapose. I added the use of Scalar::Util (if available) just in case. http://www.wafu.ne.jp/~daisuke/Data-Juxtapose-0.01.tar.gz Let me know if there are any problems. If I don't hear anything, I'll probably upload it to CPAN tomorrow. --d
Re: patch: DateTime::TimeZone PP redundant structures
Matt, Dave, I like this... but I'd like to generalize this juxtapose thing into a separate package and release it, if it's okay with you guys (especially Matt)? Something as simple as this: my $j = Juxtapose-new; @data = $j-juxtapose(@data); If ok, do you guys have any suggestions for the name of the module? Meanwhile I did a massive update of the XS code, so I need to integrate all that with this. whoof. --d
Re: DateTime::TimeZone in XS is ready in CVS
You can't look at this to determine how big it really is. I'm pretty sure Devel::Size doesn't look at the C data structure. You should use the script I sent in an earlier email along with top or something like that. You may have already fixed it ;) eh, no. I've been looking at top with your script, and the VSIZE is consistently bigger with the XS modules. I see more shared memory too, though. PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE 1977 perl 0.0% 0:03.27 112 1177 14.6M 13.4M 21.9M 51.0M Hmm, RSHRD = 13.7, RSIZE = 21.9, so the unique memory used by this process is 8.2MB? Is that what I should be looking at? Just as comparison, the pure perl version is 1991 perl 0.0% 0:02.89 11246 13.4M 1.38M 14.6M 33.3M so RSHRD = 1.38M, RSIZE = 14.6M, and the difference = 12.22MB Argh, I don't get it. --d
Re: DateTime::TimeZone in XS is ready in CVS
FWIW I've come down to around 900 bytes per structure (max), and yet still 10MB more memory is consumed at this point. Hmmm. --d
Re: DateTime::TimeZone in XS is ready in CVS
But I'm still rather mystified. How can the C structs possibly be bigger than Perl's data structures? I'm thinking the memory inefficiency + the way util.o is one of the culprits. let me try a few tests... --d
DateTime::TimeZone test patch to work with DateTime = 0.29
DateTime 0.29 made changes to the date math wrt to DST, so tests that
expected to fail when resulting datetime is invalid now are complaining.
I haven't checked all the tests yet, but here's at least one...
Index: t/09changes.t
===
RCS file: /cvsroot/perl-date-time/modules/DateTime-TimeZone/t/09changes.t,v
retrieving revision 1.15
diff -d -u -r1.15 09changes.t
--- t/09changes.t 20 Oct 2003 15:11:47 - 1.15
+++ t/09changes.t 6 Jul 2005 06:55:31 -
@@ -313,9 +313,12 @@
hour = 2,
time_zone = 'America/Chicago',
);
-
-eval { $dt-add( days = 1 ) };
-like( $@, qr/Invalid local time .+/, 'exception for invalid time
produced via add' );
+SKIP: {
+skip 'DateTime = 0.29 does not have this problem', 1 if
+$DateTime::VERSION = 0.29;
+eval { $dt-add( days = 1 ) };
+like( $@, qr/Invalid local time .+/, 'exception for invalid
time produced via add' );
+}
}
{
[RESEND] DateTime::TimeZone test patch to work with DateTime = 0.29
(Resending out of fear that mail from my other account will get rejected)
DateTime 0.29 made changes to the date math wrt to DST, so tests that
expected to fail when resulting datetime is invalid now are complaining.
I haven't checked all the tests yet, but here's at least one...
Index: t/09changes.t
===
RCS file: /cvsroot/perl-date-time/modules/DateTime-TimeZone/t/09changes.t,v
retrieving revision 1.15
diff -d -u -r1.15 09changes.t
--- t/09changes.t 20 Oct 2003 15:11:47 - 1.15
+++ t/09changes.t 6 Jul 2005 06:55:31 -
@@ -313,9 +313,12 @@
hour = 2,
time_zone = 'America/Chicago',
);
-
-eval { $dt-add( days = 1 ) };
-like( $@, qr/Invalid local time .+/, 'exception for invalid time
produced via add' );
+SKIP: {
+skip 'DateTime = 0.29 does not have this problem', 1 if
+$DateTime::VERSION = 0.29;
+eval { $dt-add( days = 1 ) };
+like( $@, qr/Invalid local time .+/, 'exception for invalid
time produced via add' );
+}
}
{
Re: DateTime.pm on a Diet
Dave,
I agree about taking it with a grain of salt.
However,
a) it is true that DateTime is slow (compared to other alternatives), and
b) It's just not good that we give people excuse like this to
not to use DateTime or to make it look like DateTime is not up to par
So I think we should be taking the performance issue seriously.
Anyway, before people rush off down various paths I'd suggest some
profiling and benchmarking, rather than just making it faster.
I lost the data along the way, but if I remember correctly, the
slowest bits were:
- DateTime::new
- Params::Validate
- timezones or locales (I forget)
- date math
(It took way too long to generate the profiling data, so I really
don't feel like taking it again...)
The first question to answer is what are people doing with these
objects? I suspect the biggest benefit would be simply to speed up
object creation, rather than the datetime math bits. Secondly, I think
slimming down time zones would be a big win (for memory savings), and
speeding them up would be nice although not necessarily that
noticeable. After that improving datetime math would be good, I think.
From looking at the code, I think there are still much more that can
be done in XS. Let's take DateTime-new, for example. When called,
new() calls these functions from within:
_ymd2rd (XS)
_time_as_seconds (XS)
_normalize_nanoseconds
_calc_utc_rd
_handle_offset_modifier
_calc_local_rd
The last 4 functions can definitely be implemented in C -- they are
probably good candidates, too, because most of they are mostly
responsible for doing integer arithmatic that is much better handled
in C.
I also would like to suggest that it might make sense to put most of
the data in C structs, e.g.
struct dt {
long utc_rd_days;
long utc_rd_secs;
long local_rd_days;
long local_rd_secs;
...
};
# DateTime's blessed hash would look like
#
# { _xs_state = $c_struct, ... other fields }
Then we'd be manipulating the dt-utc_rd_days, dt-utc_rd_secs, etc
fields directly instead of SVs. This way we can do probably 90% of the
internal calculations in C, and we can also minimize the memory foot
print.
To summarize... I was already looking at writing Locales in C (looks
like that mail didn't get sent to the list...(*1)) and minimizing the
foot print for DT::Duration, but I suppose I can do TimeZones first?
(*1) http://www.nntp.perl.org/group/perl.datetime/5859
P.S. - attached is a patch for DT::Locale in XS (there are still test failures)
--d
xs-locale.patch
Description: Binary data
generate_xs_from_icu
Description: Binary data
Please Ignore, This is a Test
Some of my mails to datetime@perl.org seem to have vanished before reaching the mail list... this is just a test. please ignore.
Re: DT::C::Chinese fails a bunch of tests
Eh, sorry. That's what you get for programming while you've only had an hour of sleep in two days. I think there were a few minor changes that I had added after 0.03. I'll take this as a chance to release those and review the release. --d Dave Rolsky wrote: On Tue, 28 Jun 2005, Hill, Ronald wrote: I am testing this and am unable to install. DateTime-calendar-chinese requires 'DateTime::Event::Chinese' = '= 0.04', But I checked CPAN it only goes to version 0.03 Have you not yet uploaded the new version to CPAN yet? I noticed this too. It passed all its tests anyway. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: DT::C::Chinese fails a bunch of tests
I actually jsut noticed this a few weeks ago, and have beed trying to get to the bottom of it -- except, for some reason I just can't install Math::BigInt::GMP on my laptop. arrrgh. Some underlying modules have changed since last time these tests passed: - DT::E::Lunar - DT::Util::Astro - DT::Util::Calc - DT::Set Got to get this GMP craziness over with first, though. hmm. --d Dave Rolsky wrote: I just tried to install this on a new box and it failed a bunch of the tests in 01-sanity.t Here's the output: t/01-sanity# # *** This test will take a long time, please be patient *** # *** Starting on Mon Jun 27 16:21:19 2005 # Failed test (t/01-sanity.t at line 60) # got: '亥' # expected: '未' # Failed test (t/01-sanity.t at line 62) # got: 'hai4' # expected: 'wei4' # Failed test (t/01-sanity.t at line 63) # got: 'pig' # expected: 'sheep' # Failed test (t/01-sanity.t at line 54) # got: '0' # expected: '20' # Failed test (t/01-sanity.t at line 57) # got: '1' # expected: '2' # Failed test (t/01-sanity.t at line 60) # got: '亥' # expected: '未' # Failed test (t/01-sanity.t at line 62) # got: 'hai4' # expected: 'wei4' # Failed test (t/01-sanity.t at line 63) # got: 'pig' # expected: 'sheep' # Failed test (t/01-sanity.t at line 66) # got: '724248' # expected: '731543' # Looks like you failed 9 tests of 38. dubious Test returned status 9 (wstat 2304, 0x900) DIED. FAILED tests 10, 12-13, 17, 20, 22, 24-26 Failed 9/38 tests, 76.32% okay Failed 1/1 test scripts, 0.00% okay. 9/38 subtests failed, 76.32% okay. Failed Test Stat Wstat Total Fail Failed List of Failed --- t/01-sanity.t9 2304389 23.68% 10 12-13 17 20 22 24-26 Anyone have any ideas why? I was hoping to use it as an example in my datetime talk at YAPC but oh well. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: DT::C::Chinese fails a bunch of tests
Okay, I got GMP installed. seems like terrestrial branch is broken, but the rest is ok on my machine. looking into it... --d @ sleepless in Tokyo (5:54am) Daisuke Maki wrote: I actually jsut noticed this a few weeks ago, and have beed trying to get to the bottom of it -- except, for some reason I just can't install Math::BigInt::GMP on my laptop. arrrgh. Some underlying modules have changed since last time these tests passed: - DT::E::Lunar - DT::Util::Astro - DT::Util::Calc - DT::Set Got to get this GMP craziness over with first, though. hmm. --d Dave Rolsky wrote: I just tried to install this on a new box and it failed a bunch of the tests in 01-sanity.t Here's the output: t/01-sanity# # *** This test will take a long time, please be patient *** # *** Starting on Mon Jun 27 16:21:19 2005 # Failed test (t/01-sanity.t at line 60) # got: '亥' # expected: '未' # Failed test (t/01-sanity.t at line 62) # got: 'hai4' # expected: 'wei4' # Failed test (t/01-sanity.t at line 63) # got: 'pig' # expected: 'sheep' # Failed test (t/01-sanity.t at line 54) # got: '0' # expected: '20' # Failed test (t/01-sanity.t at line 57) # got: '1' # expected: '2' # Failed test (t/01-sanity.t at line 60) # got: '亥' # expected: '未' # Failed test (t/01-sanity.t at line 62) # got: 'hai4' # expected: 'wei4' # Failed test (t/01-sanity.t at line 63) # got: 'pig' # expected: 'sheep' # Failed test (t/01-sanity.t at line 66) # got: '724248' # expected: '731543' # Looks like you failed 9 tests of 38. dubious Test returned status 9 (wstat 2304, 0x900) DIED. FAILED tests 10, 12-13, 17, 20, 22, 24-26 Failed 9/38 tests, 76.32% okay Failed 1/1 test scripts, 0.00% okay. 9/38 subtests failed, 76.32% okay. Failed Test Stat Wstat Total Fail Failed List of Failed --- t/01-sanity.t9 2304389 23.68% 10 12-13 17 20 22 24-26 Anyone have any ideas why? I was hoping to use it as an example in my datetime talk at YAPC but oh well. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: [repost] two small fixes for DateTime::Format::Pg
It is supposed to be feature-complete, yes. What _can_ happen anytime is that the DateTime API changes in an incompatible way (very unlikely, although it has already happened) or that PostgreSQL adds some more formats. However, what really needs some work is the test suite. It does not test all methods at the moment which is the main cause why bugs in less used code paths can slip in. right, I consider that part of maintenance ;) Well, I'm game unless Cees really wants to do it :) Cees? --d
Re: [repost] two small fixes for DateTime::Format::Pg
If there's nobody else, I don't mind being the maintainer, except I doubt that I'll be doing much more than maintenance (as opposed to active development). I should be able to respond in time in cases like these, though. Claus, the module is pretty much stable nowadays, right? --d Claus Färber wrote: Hallo, John Siracusa [EMAIL PROTECTED] schrieb/wrote: On 3/15/05 11:54 PM, Cees Hek wrote: I sent a bug report and patch to this list back in January [1] regarding DateTime::Format::Pg, and I never received a response. Just wondering if this slipped through the cracks. In the meantime, I have logged this as a bug in rt.cpan.org [2]. I think the DateTime::Format::Pg is officially MIA. I filed a bug 4 months ago and have tried to contact the author many times. Sorry about that. I'm afraid all of the messages went into the spam folder where they did not stand out enough for me to notice them (unfortunatly, both the spam filter and my brain seem to be biased against messages written in English as I rarely get English non-spam messages). I stopped reading the mailing list regularily due to lack of time. Does someone want to take over DateTime::Format::Pg? As I've already said, I don't have too much time at the moment. If there's someone else willing to maintain the module, this might be better. In the meantime, I'll upload a new version of DT::F::Pg. Claus
Re: Bug: DT::Event::Recurrence Modifies Params
I noticed a little bug today. DateTime::Event::Recurrence modifies the
parameters that are passed to it.
I suspect these lines..
Index: lib/DateTime/Event/Recurrence.pm
===
RCS file:
/cvsroot/perl-date-time/modules/DateTime-Event-Recurrence/lib/DateTime/Event/Recurrence.pm,v
retrieving revision 1.85
diff -d -u -r1.85 Recurrence.pm
--- lib/DateTime/Event/Recurrence.pm22 Sep 2004 16:19:23 - 1.85
+++ lib/DateTime/Event/Recurrence.pm7 Jan 2005 09:58:58 -
@@ -684,11 +684,11 @@
if ( $unit eq 'days' )
{
# map rfc2445 weekdays to numbers
-@{$args{$unit}} = map {
+$args{$unit} = [ map {
$_ =~ /[a-z]/ ?
$_ = $weekdays{$_} :
$_
-} @{$args{$unit}};
+} @{$args{$unit}} ];
}
@{$args{$unit}} = sort { $a = $b } @{$args{$unit}};
# put positive values first
However, I don't think this solves the whole problem.
It looks like there are a lot of
@{ $args { $foo } } = @blah_blah;
type of constructs, and that's where this is all coming from.
If no one objects, I don't mind doing a sweep change and remove all such
occurences. It's a three day weekend over in this corner of Asia.
--d
Re: Bug: DT::Event::Recurrence Modifies Params
can Flavio/Dave/somebody review this code?
I basically opted to copy over $args{$unit} to a different array before
doing any processing, and refactored one bit of code.
All existing tests passed.
--d
Index: lib/DateTime/Event/Recurrence.pm
===
RCS file:
/cvsroot/perl-date-time/modules/DateTime-Event-Recurrence/lib/DateTime/Event/Recurrence.pm,v
retrieving revision 1.85
diff -d -u -r1.85 Recurrence.pm
--- lib/DateTime/Event/Recurrence.pm22 Sep 2004 16:19:23 - 1.85
+++ lib/DateTime/Event/Recurrence.pm8 Jan 2005 00:54:16 -
@@ -619,6 +619,15 @@
return $set;
}
+sub _sort_positive_first
+{
+my @sorted = sort { $a = $b } @_;
+# put positive values first
+my @ret = grep { $_ = 0 } @sorted;
+push @ret, $_ for grep { $_ 0 } @sorted;
+
+return @ret;
+}
# method( hours = 10 )
# method( hours = 10, minutes = 30 )
@@ -676,8 +685,13 @@
next unless exists $args{$unit};
-$args{$unit} = [ $args{$unit} ]
-unless ref( $args{$unit} ) eq 'ARRAY';
+# copy the argument values before proceeding, so that we
+# don't accidentally modify it.
+if (ref($args{$unit}) eq 'ARRAY') {
+$args{$unit} = [ @{$args{$unit}} ];
+} else {
+$args{$unit} = [ $args{$unit} ];
+}
# TODO: sort _after_ normalization
@@ -690,13 +704,7 @@
$_
} @{$args{$unit}};
}
-@{$args{$unit}} = sort { $a = $b } @{$args{$unit}};
-# put positive values first
-# warn Arguments: $unit = @{$args{$unit}};
-my @tmp = grep { $_ = 0 } @{$args{$unit}};
-push @tmp, $_ for grep { $_ 0 } @{$args{$unit}};
-# print STDERR $unit = @tmp\n;
-@{$args{$unit}} = @tmp;
+$args{$unit} = [ _sort_positive_first(@{$args{$unit}}) ];
$ical_string .= uc( ';' . $ical_name{$unit} . '=' .
join(,, @{$args{$unit}} ) ) unless $unit eq 'nanoseconds';
@@ -755,14 +763,7 @@
}
# redo argument sort
-
-@{$args{$unit}} = sort { $a = $b } @{$args{$unit}};
-# put positive values first
-my @tmp = grep { $_ = 0 } @{$args{$unit}};
-push @tmp, $_ for grep { $_ 0 } @{$args{$unit}};
-# print STDERR $unit = @tmp\n;
-@{$args{$unit}} = @tmp;
-
+$args{$unit} = [
_sort_positive_first(@{$args{$unit}}) ];
}
else
{ # year day
Re: [Perl-date-time-dev] Lots a changes.
when you say make it a method, do you mean to make the cache an instance variable, or are you talking about just how it gets called? bleh. instance variables? what am I saying. There are only functional interface to this module... I'm guessing this is kind of what you are talking about: DateTime::Util::Astro::Moon::set_cache($cache); my $cache = DateTime::Util::Astro::Moon::get_cache(); --d
Re: support for precision?
That's the right behavior because DateTime represents a point in time. 2004 represents 1 year, a span of time. What exactly do you want to do? --d Mark D. Anderson wrote: There seems to be no support for keeping track of precision? In particular, suppose my original string is 2004. I would like to later print that out as 2004, *not* as 2004-01-01, because somehow the DateTime object kept track of the level of precision. But in this code: my $dt = DateTime-new(year = 2004); print year=, $dt-year, month=, $dt-month, \n; the output is: year=2004 month=1 I can't specify an illegal value like -1. And there is no way to turn off the builtin defaulting. -mda
Re: [PATCH] Re: new fan has questions/comments/suggestions
Eek, this is evil. You have an object method that is a constructor, but the constructed object really has nothing to do with the object on which you call the constructor. How is this better than just calling parse_datetime on the relevant DT::Format class or object? I note that you didn't write any tests for it. Maybe some part of you secretly rebelled against its evilness. Oh oops, now that you mention it.. No evilness involved there. Just thought that if you have a formatter that can format and parse, you might as well do both. I can surely live without having that method. Is the rest ok? --d
Re: [PATCH] Re: new fan has questions/comments/suggestions
Removed parse_datetime, and added some documentation. And it's checked in... --d Dave Rolsky wrote: On Thu, 2 Sep 2004, Daisuke Maki wrote: No evilness involved there. Just thought that if you have a formatter that can format and parse, you might as well do both. I can surely live without having that method. Is the rest ok? Yep, looks good. Feel free to check it in. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: new fan has questions/comments/suggestions
HOWEVER, that said, I'd like to see some sort of a default format method: $dt-set_default_format($strftime_format); print $dt-default_format; print Stringified with default: $dt; Someone came up to me at OSCON and asked about whether I wanted a patch for this and I said yes. I think it might've been Michael Schwern. I'd prefer being able to pass a formatter: http://marc.theaimsgroup.com/?l=perl-datetimem=108995979225140w=2 Then if your formatter supports strftime notation, you could just do my $dt = DateTime-new( ..., formatter = My::Formatter-new(pattern = $strftime_pattern) ); print $dt\n; This has a significant advantage for non-English users who just want their DT objects magically appear in the format of their choice... (Although, now that I think about it this raises a problem with cyclic dependencies between DateTime and the default formatter (presumably DT::F::Strptime) --d
Re: problem with leap_month in DateTime::Calendar::Chinese
I'm trying to use DateTime::Calendar::Chinese to calculate public holidays for Hong Kong, as illustrated by this output from a test script, included below. For 2004, Chinese New Year is 22 January, and there is a leap month after the second lunar month. Buddah's Birthday is the 8th day of the 4th lunar month, so (taking into account the leap month) that is 26 May. My script returns 26 April. Similarly, Tuen Ng is the 5th day of the 5th month, that is 22 June, but my script returns 23 May. The table after New Moons, Month starts lists the dates of new moons, the first day of the month with leap_month = 0 and the first day of the month with leap_month = 1. There is no difference between the last two columns: setting leap_month does nothing. I've finally pulled out my copy of Calendrical Calculations and have been rewriting tests for DateTime::Calendar::Chinese, and apparently the conversion from Chinese date components to gregorian components is mightly screwed up... And this in turn seems to be a problem in DateTime::Event::Chinese. new_year_before() is returning future dates(!) Still poking around... --d
Re: Bug: Storable on Infinite Dates Broken
Assuming the tests pass, please feel free to check it in. all tests passed. checked in. --d
Re: Bug: Storable on Infinite Dates Broken
From the Storable docs:
The first time the hook is hit in a serialization flow, you may
have it return an empty list. That will signal the Storable engine
to further discard that hook for this class and to therefore revert
to the default serialization of the underlying Perl data. The hook
will again be normally processed in the next serialization.
I think this is the behavior that we'd want I think (the wording is
a bit ambiguous to me, but it sounds like it)
And here's the test to go with it.
Your wish is my command ;)
Index: t/23storable.t
===
RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/t/23storable.t,v
retrieving revision 1.2
diff -d -u -r1.2 23storable.t
--- t/23storable.t 6 Jul 2003 16:48:37 - 1.2
+++ t/23storable.t 2 Aug 2004 07:46:02 -
@@ -8,7 +8,7 @@
if ( eval { require Storable; 1 } )
{
-plan tests = 5;
+plan tests = 15;
}
else
{
@@ -16,29 +16,34 @@
}
{
-my $dt =
+my @dt = (
DateTime-new( year = 1950,
hour = 1,
nanosecond = 1,
time_zone = 'America/Chicago',
language = 'German'
- );
-
-my $copy = Storable::thaw( Storable::nfreeze($dt) );
-
-is( $copy-time_zone-name, 'America/Chicago',
-'Storable freeze/thaw preserves tz' );
-
-is( ref $copy-locale, 'DateTime::Locale::de',
-'Storable freeze/thaw preserves locale' );
-
-is( $copy-year, 1950,
-'Storable freeze/thaw preserves rd values' );
-
-is( $copy-hour, 1,
-'Storable freeze/thaw preserves rd values' );
+ ),
+DateTime::Infinite::Past-new,
+DateTime::Infinite::Future-new,
+);
-is( $copy-nanosecond, 1,
-'Storable freeze/thaw preserves rd values' );
+foreach my $dt (@dt) {
+my $copy = Storable::thaw( Storable::nfreeze($dt) );
+
+is( $copy-time_zone-name, $dt-time_zone-name,
+'Storable freeze/thaw preserves tz' );
+
+is( ref $copy-locale, ref $dt-locale,
+'Storable freeze/thaw preserves locale' );
+
+is( $copy-year, $dt-year,
+'Storable freeze/thaw preserves rd values' );
+
+is( $copy-hour, $dt-hour,
+'Storable freeze/thaw preserves rd values' );
+
+is( $copy-nanosecond, $dt-nanosecond,
+'Storable freeze/thaw preserves rd values' );
+}
}
Dave Rolsky wrote:
On Mon, 2 Aug 2004, Daisuke Maki wrote:
I supppose something like this would fix the problem?
Index: lib/DateTime/Infinite.pm
===
RCS file:
/cvsroot/perl-date-time/modules/DateTime.pm/lib/DateTime/Infinite.pm,v
retrieving revision 1.8
diff -d -u -r1.8 Infinite.pm
--- lib/DateTime/Infinite.pm24 Jul 2003 04:24:16 - 1.8
+++ lib/DateTime/Infinite.pm2 Aug 2004 07:23:17 -
@@ -27,6 +27,9 @@
return ($_[1]) x 3;
}
+sub STORABLE_freeze { return }
+sub STORABLE_thaw { return }
It does? Won't this just freeze nothing? I think we need some tests ;)
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
DateTime::Format::Pg with time zone
Hi,
just a FYI.
My db of choice is Postgres, and hence I use DateTime::Format::Pg a lot,
but there's a little bit of problem when it comes to dealing with
datetime types with time zone.
DateTime.pm apparently only supports offset strings in the form of
[-+]\d\d\d\d
such as
+0900
but this fails:
+09
my installation of Postgres, which had a default setting as far as time
zones come, prints out time offsets in the form of +09, not +0900, so
this was causing problems.
I don't know what the best solution is (fix datetime.pm so that it
accepts +09? fix Pg.pm else where?), but here's a hack that worked for me:
Index: lib/DateTime/Format/Pg.pm
===
RCS file:
/cvsroot/perl-date-time/modules/DateTime-Format-Pg/lib/DateTime/Format/Pg.pm,v
retrieving revision 1.11
diff -d -u -r1.11 Pg.pm
--- lib/DateTime/Format/Pg.pm 20 Jun 2004 08:46:04 - 1.11
+++ lib/DateTime/Format/Pg.pm 1 Aug 2004 23:17:58 -
@@ -324,6 +324,11 @@
$args{'parsed'}-{'time_zone'} = $stz || 'floating';
}
+ # Fix time offset where the time zone is [-+]\d\d (add 00 to the end)
+ #
+ elsif($args{'parsed'}-{'time_zone'} =~ /^[-\+]\d\d$/) {
+$args{'parsed'}-{'time_zone'} = $args{'parsed'}-{'time_zone'} . 00;
+ }
return 1;
}
--d
Re: problem with leap_month in DateTime::Calendar::Chinese
Allan Dyer wrote:
Hi
Thanks for creating an interesting package.
I'm trying to use DateTime::Calendar::Chinese to calculate public holidays for
Hong Kong, as illustrated by this output from a test script, included below.
For 2004, Chinese New Year is 22 January, and there is a leap month after the
second lunar month. Buddah's Birthday is the 8th day of the 4th lunar month, so
(taking into account the leap month) that is 26 May. My script returns 26
April. Similarly, Tuen Ng is the 5th day of the 5th month, that is 22 June, but
my script returns 23 May.
The table after New Moons, Month starts lists the dates of new moons, the
first day of the month with leap_month = 0 and the first day of the month with
leap_month = 1. There is no difference between the last two columns: setting
leap_month does nothing.
Well, the modules *does* look at the leap_month, but there's obviously
something wrong if it's not making any difference in any of the dates
calculated.
my $prior_new_moon;
if ($d-month == $self-month $d-leap_month == $self-leap_month) {
$prior_new_moon = $p;
} else {
$prior_new_moon = DateTime::Event::Lunar-new_moon_after(
datetime= $p + DateTime::Duration-new(days = 1),
on_or_after = 1);
}
I unfortunately don't have my copy of Calendrical Calculations with me
right now so I can't double check, but I do admit there are cases where
my code misses the dates somehow If you happen to be able to pin
point a test case, pls let me know..
BTW
Base: 2004-01-01 00:00:00
Sui:2004-01-22 12:00:00
Greg: 2004-01-22 12:00:00
New Moons, Month starts
2004-01-22 12:00:00 2004-02-20 00:00:00 2004-02-20 00:00:00
Oh shucks...
--d
Re: [cpan #6981] Default stringification format (fwd)
Its really important that date objects masquarade well as strings so you don't have to
redesign your whole interface when you introduce them. DateTime currently only
stringifies as an ISO8601 date. This is limiting. To get it in any other format you
have to drop down to a plain string which sorta defeats the point.
DateTime should have a default_format() method that takes a strftime pattern. This is
the format it will use when stringifing.
I'm writing a subclass that does this for my own purposes. Let me know if you think its a good idea and want a patch.
I was just thinking how I would use it, but this would be kind od nice...
use DateTime;
use DateTime::Format::Japanese;
my $dt = DateTime-now(formatter = DateTime::Format::Japanese-new);
print today is $dt!\n;
# internally calls $dt-format_datetime(), which proxies to
# formatter object
And similarly,
$dt-parse_datetime($some_datetime_string);
This will allow me to stringify DateTime objects in Japanese :)
We have a relatively standardized interface for formatters, so this
sounds like a relatively painless thing to add.
Here's a (badly written) patch that just shows how this might work...
===
RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/lib/DateTime.pm,v
retrieving revision 1.284
diff -r1.284 DateTime.pm
61c61
'' = 'iso8601',
---
'' = 'format_datetime',
159a160
formatter = { type = OBJECT, optional = 1 }
197a199,200
$self-{formatter} = $p{formatter};
339a343
formatter = { type = OBJECT, optional = 1 },
378a383
formatter = { type = OBJECT, optional = 1 },
485a491,492
sub formatter{ $_[0]-{formatter} }
625a633,654
sub parse_datetime
{
my $self = shift;
my $string = shift;
if (!$self-{formatter} || !UNIVERSAL::can($self-{formatter},
'parse_datetime')) {
die Not formatter available (or formatter can't do
parse_datetime());
}
$self-{formatter}-parse_datetime($string);
}
sub format_datetime
{
my $self = shift;
if (!$self-{formatter} || !UNIVERSAL::can($self-{formatter},
'format_datetime')) {
return $self-iso8601;
} else {
return $self-{formatter}-format_datetime($self);
}
}
1389a1419,1426
sub set_formatter
{
my $self = shift;
my $formatter = shift;
$self-{formatter} = $formatter;
}
--d
Re: [cpan #6980] $d-day(1); == $d-set(day = 1); (fwd)
I agree that there is an awkward-ness in the way accessors and mutators work in DateTime.pm, but one thin I'd like to keep note of is that $dt-set() should be preserved, if not only for performance's sake because set() can be used to set multiple fields all at once, reducing the amount of calculation. If we do change the naming, I vote for $dt-day; $dt-day(1); But I'm not too annoyed about this particular naming thing... --d David Wheeler wrote: On Jul 15, 2004, at 2:40 PM, Dave Rolsky wrote: $d-day(1) and friends should be the equivalent of $d-set(day = 1) to make the interface consistent and obvious. Hrm. I'm inclined to agree, I think. I like having separate accessors and mutators but DateTime's current model: $d-day; # accessor $d-set_day(1); # mutator Has a different naming convention for the two types of methods. I kind of like it, but only in environments where attributes are virtually always READ, and rarely WRITTEN. So maybe it should be: # Perl-style $d-day; # accessor $d-day(1); # mutator Or: # Java-style $d-get_day; # accessor $d-set_day(1); # mutator Thoughts? David
Re: Moving to subversion?
Hmmm, I haven't used Subversion before, but as long as there's something for OS X, it's fine... (And speaking of which: http://www.pycs.net/bbum/2004/3/16/). Too bad we can't just get a free copy of Perforce. I really enjoyed it at my previous work. Now I need to go read about svn. --d Dave Rolsky wrote: I'm getting fed up with the damn sourceforge CVS instability and slowness. What do people think of moving to Subversion, hosted either on my own box (svn.urth.org) or maybe svn.perl.org if I can talk Ask and/or Robert into it? I'd convert the existing CVS repo, and since we don't have any branches (AFAIK), it should work fine (tags convert ok, IIRC). Subversion runs on Windows (and there's a binary installer), Linux, BSDs, Solaris, and Mac OS X. Objections? Comments? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Converting the sunrise module to use DateTime-util-calc
That would be because I'm stupid and blindly copied sin_deg(), cos_deg()
to asin_deg() and acos_deg().
Fix coming...
--d
Hill, Ronald wrote:
Hi All,
I am in the process of converting the DateTime-Event-Sunrise module
to use the DateTime-util-calc module. The problem I am having is
using the acos_deg function in the cals module does not product
the same results as my acosd function. Can someone tell me how
I can get these 2 functions to agree? Am I doing something wrong?
the output is:
F:\scriptsme.pl
t using my method: 76.1440743101727
t using util method: 1.56661657821494
F:\scripts
Here is a test script to demonstrate the problem.
use strict;
use warnings;
use Math::Trig;
use DateTime::Util::Calc qw(acos_deg);
my $RADEG = ( 180 / pi );
my $cost = 0.239481255754665;
my $t = acosd($cost);
my $z = acos_deg($cost);
print t using my method: $t\n;
print t using util method: $z\n;
sub acosd {
( $RADEG * acos( $_[0] ) );
}
__END__
from Pauls c code whis is what I use in my module
#define RADEG ( 180.0 / PI )
#define DEGRAD( PI / 180.0 )
/* The trigonometric functions in degrees */
#define sind(x) sin((x)*DEGRAD)
#define cosd(x) cos((x)*DEGRAD)
#define tand(x) tan((x)*DEGRAD)
#define atand(x)(RADEG*atan(x))
#define asind(x)(RADEG*asin(x))
#define acosd(x)(RADEG*acos(x))
#define atan2d(y,x) (RADEG*atan2(y,x))
Thanks
Ron Hill
Re: DateTime::Calendar::Japanese 0.03 - problem _new from DateTim e::Event::Sunrise
Judging by the name, I'd assume _new() was intended for internal use. Daisuke got what he deserved for using private methods. Yep, and it is noted (I think) in the module comments -- because that public method wasn't available in the previous version of Sunrise.pm (For some reason it worked for me before, I must have the older version) Will fix it. --d
Re: DateTime::Calendar::Japanese 0.03 - problem _new from DateTim e::Event::Sunrise
Oooops!, I did not note that in the change log :( Anyway, Daisuke Maki needs to update his module to use the new method as there is no more _new and update the dependencies as will. I have a request. Can you make DT::E::Sunrise contain a method to give me both sunrise AND sunset for a given $dt? What I currently see is $obj-sunrise_datetime($dt); $obj-sunset_datetime($dt); But that's a slight bit of overhead since you have to call the internal function _sunrise() twice. my($rise, $set) = $obj-sunrise_sunset($dt) or something like that would be nice. Meanwhile, will fix 0.03 to use sunrise_datetime() and sunset_datetime()... --d
Re: DateTime::Calendar::Japanese 0.03 - problem _new from DateTim e::Event::Sunrise
Or, am I suppose to use the sunrise_sunset_span? I think so. fixin'... --d I have a request. Can you make DT::E::Sunrise contain a method to give me both sunrise AND sunset for a given $dt? What I currently see is $obj-sunrise_datetime($dt); $obj-sunset_datetime($dt); But that's a slight bit of overhead since you have to call the internal function _sunrise() twice. my($rise, $set) = $obj-sunrise_sunset($dt) or something like that would be nice. Meanwhile, will fix 0.03 to use sunrise_datetime() and sunset_datetime()... --d
Re: patch to DT::F::Builder
That bit sets @Carp::CARP_NOT. In your code you should be setting
@Your::Module::CARP_NOT. It's intended to be set just once, like
@ISA, not just before calling carp.
Got it. I think this diff would do. Thanks for the pointer :)
Index: lib/DateTime/Format/Builder.pm
===
RCS file:
/cvsroot/perl-date-time/modules/DateTime-Format-Builder/lib/DateTime/F
ormat/Builder.pm,v
retrieving revision 1.36
diff -d -u -r1.36 Builder.pm
--- lib/DateTime/Format/Builder.pm 30 Jan 2004 07:09:13 - 1.36
+++ lib/DateTime/Format/Builder.pm 4 Feb 2004 09:07:14 -
@@ -14,7 +14,7 @@
use Params::Validate qw(
validate SCALAR ARRAYREF HASHREF SCALARREF CODEREF GLOB GLOBREF UNDEF
);
-use vars qw( $VERSION %dispatch_data );
+use vars qw( $VERSION %dispatch_data @CARP_NOT );
my $parser = 'DateTime::Format::Builder::Parser';
$VERSION = '0.7801';
@@ -201,13 +201,8 @@
{
my ($class, $input) = @_;
-my $pkg;
-my $i = 0;
-while (($pkg) = caller($i++)) {
-last if (!UNIVERSAL::isa($pkg, 'DateTime::Format::Builder')
-!UNIVERSAL::isa($pkg, 'DateTime::Format::Builder::Parser'));
-}
-local $Carp::CarpLevel = $i;
+local @CARP_NOT =
+qw(DateTime::Format::Builder DateTime::Format::Builder::Parser);
croak Invalid date format: $input;
}
Pondering about DT::F::Japanese
So now I'm pondering on Ricks' suggestion that I should make DT::F::Japanese behave more like (strp|strf)time. This is mainly me talking to myself, but please pitch in if you have any ideas (especially if you speak/read/write Japanese -- I know you guys are out there) First, I need to enumerate the possible formats: - General Number Representation: - roman (ascii) - double-byte roman - double-byte kanji - Year Representation - by gregorian - by gregorian, with gregorian marker - by gregorian, with A.C./B.C. marker - by Japanese era (mutually exclusive with the above three) - Month representation - month-number followed by month kanji - traditional month names (to be implemented with DT::F::J::Traditional) - Time - Am/Pm - modern notation - traditional notation (to be implemented with DT::F::J::Traditional) - Miscellaneous - Day of week - There's this thing that assigns names to each date in cycle of 6 days, which I may or may not add (requires traditional calendar) My main concerns in trying to encode this into a (strp|strf)time-ish format are as follows: - Encoding is actually a combination of number representation and whatever else format. for example, the era notation is actually 1) era/roman 2) era/double-byte roman 3) era/kanji. - I personally think that the encoding scheme for (strp|strf)time is horrendous in some cases -- %[a-zA-Z] is just confusing sometimes -- it certainly doesn't make it easier for the Japanese audience - I'm already jumping through hoops trying to write regexps that match unicode Japanese. Will this add even more to the pain? Hmmm, I guess I'm just having a hard time trying to picture what it is that I gain while I feel that I lose a lot of the ease of use and maintainability by adding this (strp|strf)time-ish generalization on the formatting. But I may be wrong. Please let me know if you have any comments on this. --d
A Time-only namespace?
I'd like to rip out the traditional Japanese time support from DT::C::Japanese and place it on its own module, so that a) I can use it for Gregorian-based calendars and b) I can test it more thoroughly (presumably it will be much faster, because I wouldn't have to worry about calculating lunar/solar longitudes every time I want to test it :) Now I noticed there isn't a namespace for this under DateTime. Is there any namespace that is recommended? I guess it may not make sense to put it under DateTime::, so would something like Time::Japanese work? --d
Re: DateTime::Format::Japanese
use DateTime::Format::Japanese; my $fmt = DateTime::Format::Japanese-new( number_format = FORMAT_KANJI, year_format = FORMAT_ERA, with_gregorian_marker = 1, with_bc_marker= 1, with_ampm_marker = 1, with_day_of_week = 1 ); With all these options, aren't we better off to make this a strp/strf type module? That's fine. I just couldn't come up with a good encoding (One of my personal programming mantra is that I would never try to invent a language/encoding/protocol unless I absolutely have to, and well, this to me didn't seem like a good candidate). But hey, if there's a good scheme, I'm all ears. I'd suggest this module should be the latter and just have it return kanji characters rather than latin. Hmm? It does that already. My hunch is that you're talking about FORMAT_ROMAN, but that's not saying that the entire string is in latin, the numeric components are latin (and, as wacked up group of people that we are, we use roman numerals and double-byte numerals liberally within the same document) --d
DT::F::Japanese to sourceforge CVS
all, this is just a heads up so that you know I'm going to be committing DateTime::Format::Japanese (still in progress) into sourceforge CVS. Let me know if there are any problems with namespace or any other concerns. If I don't hear anything, I'm going to commit it in the next few days. thanks, --d
patch to DT::F::Builder
It was really annoying me that parsers based on DT::F::Builder would by
default report a parse failure as being in DT::F::B::Parser.
I'd like the error message to tell me where in the calling script it
failed, so I'd like to introduce this patch.
Index: lib/DateTime/Format/Builder.pm
===
RCS file:
/cvsroot/perl-date-time/modules/DateTime-Format-Builder/lib/DateTime/F
ormat/Builder.pm,v
retrieving revision 1.35
diff -d -u -r1.35 Builder.pm
--- lib/DateTime/Format/Builder.pm 26 Jan 2004 18:46:45 - 1.35
+++ lib/DateTime/Format/Builder.pm 30 Jan 2004 00:37:34 -
@@ -200,6 +200,13 @@
sub on_fail
{
my ($class, $input) = @_;
+
+my $i = 0;
+while (my ($pkg) = caller($i++)) {
+last if ($pkg ne 'DateTime::Format::Builder'
+$pkg !~ /^DateTime::Format::Builder::Parser/);
+}
+local $Carp::CarpLevel = $i;
croak Invalid date format: $input;
}
Where's the official time zone for China?
I'm trying to set the default time zone for my DT::C::Chinese to the Chinese standard time zone so that people don't accidentally use their own time zones, only to get, for example, a Chinese new year date of Jan 21 2004 (UTC) instead of the official Jan 22 2004. And I'm looking at the TimeZone catalog, and I realize there's no DT::TimeZone::Asia::Beijing, which I thought was where they base Chinese calendars. I see Hong Kong, I see Shanghai. Is one better suited over the other? Or is there some other official time zone I should be using? --d
Re: Chinese/Japanese calendars - GMP is a pre-requisite
Hi, thanks for the feedback! GMP in itself is not necessary -- it's much faster if you have it, though. Did it *force* you to install GMP? I thought I put that requirement in the recommends parameter (like this: http://search.cpan.org/src/DMAKI/DateTime-Util-Calc-0.01/Build.PL). Perhpas I don't quite understand how Module::Build works... Please let me know. From the next release on, I should make sure that GMP is an optional package, and that Math::BigInt/Math::BigFloat is the bare minimum. After that I should be able to put some code in Build.PL that probes for GMP. --d I've had an entertaining morning building Perl 5.8.3 and getting DateTime::Calendar::Japanese etc installed. Perl 5.8.3 itself was trivial - I'm glad to say. I ran into a bigger problem with DateTime::Calendar::Japanese etc -- they need the GMP (GNU Multi-Precision Math) library installed. I didn't have it, so I had to build it - twice, because the first time it opted to build 64-bit interfaces on a system (Solaris 8) where I still run mainly in 32-bit mode. With GMP built and installed, I could get Math::BigInt::GMP installed, and hence everything else. That was done first with 5.8.2 and then with 5.8.3. I don't know if there's an effective way for ensuring that a non-Perl prerequisite such as the GMP libraries are available. In DBD::Informix, my Makefile.PL does a lot of poking around to ensure that the prerequisite non-Perl ESQL/C product (library and headers) is both installed and usable - basically because I had so many people running into problems when it was not because they didn't know it was necessary. Also, when a test takes a long time, as many of yours do, you very kindly output a warning that the test will take a while, but it is really helpful to know when the test started, so you can easily determine how long the test has taken so far. So, once I had GMP installed (outside the Perl installation, but where Perl expects to find libraries), then the new modules installed OK. -- Jonathan Leffler ([EMAIL PROTECTED]) STSM, Informix Database Engineering, IBM Data Management 4100 Bohannon Drive, Menlo Park, CA 94025 Tel: +1 650-926-6921 Tie-Line: 630-6921 I don't suffer from insanity; I enjoy every minute of it!
Re: Problems installing new modules
Bah, thanks for the reminder! Ah, I don't think this is a GPG version mismatch. Daisuke, you need to put your key on a keyserver! (try pgp.mit.edu) or else no one can get it for verification.
Chinese/Japanese calendars
Well, I uploaded those modules last night and my cold medication kicked in, so there was some gap between that and this announcement, but I've finally uploaded the Chinese and Japanese calendars to CPAN: DateTime-Calendar-Chinese-0.01 DateTime-Calendar-Japanese-0.01 DateTime-Calendar-Japanese-Era-0.01 DateTime-Event-Chinese-0.01 DateTime-Event-Lunar-0.01 DateTime-Event-SolarTerm-0.01 DateTime-Util-Astro-0.01 DateTime-Util-Calc-0.01 I kind of put them out in a haste because I'm currently in the middle of packing up my life here in U.S. to move to Japan, and didn't think I'd get too much quality hacking time for the next few weeks -- hence I already realize there were some incomplete POD entries among other things (that's what I get for programming while on medication). Hopefully there are no serious problems. Comments welcome, and enjoy. --d
Re: Chinese Calendar Related Modules
I think that's because _01 modules are considered developer releases and are not installable automatically by CPAN. I've installed these modules by hand. Oops, I replied to the original poster, but I forgot to cc the group. I believe Flavio is correct. I intend to change the version number once DT::C::Chinese and DT::C::Japanese are done (currently about 90% done) --d
ANNOUNCE: Chinese Calendar Related Modules
Hi all, This is just to announce that the following modules have entered CPAN: DateTime-Event-Chinese-0.01_01 DateTime-Event-SolarTerm-0.01_01 DateTime-Event-Lunar-0.01_04 DateTime-Util-Astro-0.01_04 DateTime-Util-Calc-0.01_04 I can finally find out when Chinese New Years occur :) If you're interested, please try out and send me any comments you might have. In my TODO list are: - Come up with better tests - Ponder if I can make the above modules any faster (they are painfully slow right now) - DT::Calendar::Chinese and DT::Calendar::Japanese. The bulk of the work will probably revolve around trying to figure out how to calculate traditional Chinese and Japanese times, which are not mentioned in Calendrical Calculations. --d
how to return solar term info from DT::Set
Hi all, I'm now working on DateTime::Event::SolarTerm which will calculate the major and solar terms of the year. I'm currently using the DateTime::Set interface to do this: my $base_time = DateTime-new(...); my $major_terms = DateTime::Event::SolarTerm-major_term(); my $next = $major_terms-next($base_time); # and previous(), and interator(), etc. However, I'd like more than just the time and date of the next term to be available for the user -- namely, I'd like things like - name of the term - the solar longitude - major/minor term Now, given that the DateTime::Set interface expected next() and previous() to return DateTime objects, what's the recommended approach to providing more information than just the date/time? I can think of a couple of ways to do this. One is to return some sort of subclass of DateTime. The other is to provide a function that converts a DateTime object into some sort of SolarTerm object. The first approach seems bit of an overkill. The second suffers a significant perfomance penalty, because you would have to re-compute the solar longitude at the time to get at the information for that term. Is there any good way to do this? --d
solar_longitude_after or modulo question
Okay, I feel stupid asking this, but I have a question about a basic function, mod. My ported computations from CC become all wrong if I use Perl's built-in % operator. After a few trial and errors, it seemed like when CC mentions R = N mod M it's actually computing a fractional number. For example, 15.1 mod 4 would be 3.1. If I take that to be true, most of my computations work. However, now I'm having problems with taking a modulo of a negative value. Specifically, I'm trying to implement solar_longitude_after() (p.184) function -- but it chokes when the difference between $phi and solar_longitude($t) is a negative number to compute the value of $tau: $tau = $t + $rate * mod($phi - solar_longitude($t), 360); It seems like the output of mod() is expected to be something other than what I've been computing... (The reason I suspect that is because the solar terms that are generated by this function turns out wrong only if $phi - solar_longitude($t) is negative ). Does anybody know how this is supposed to work? I tried a bunch of things, but I just can't seem to get it right. Does anybody know how this *should* be done? TIA --d
Re: Chinese Calendar Question (fwd)
Absolutely. I've suggested DateTime::Util for helpers before. Astro::* makes sense for 'generic' astronomical calculations. DateTime specific stuff should inhabit another namespace. Okay, that makes more sense to me. How about: DateTime::Util::Calc DateTime::Util::Astro::Sun DateTime::Util::Astro::Moon DateTime::Util::Astro::Common DateTime::Util::Astro::Location ::Calc would contain things that are used for calculation, such as polynomial(). ::Sun will have solar longitude related stuff. ::Moon will have lunar longitude and new moon related calculations. ::Location is a simple class to encapsulate location on earth. ::Common will have things like nutation() and ephemeris_correction(). --d
[RFC] Astro related modules
I've now re-organized the astronomical calculation portions of the chinese calendar modules into the following. This should be nicer to the namespace. Please let me know if they look ok: http://www.wafu.ne.jp/~daisuke/DateTime-Util-Calc-0.01.tar.gz http://www.wafu.ne.jp/~daisuke/DateTime-Util-Astro-0.01.tar.gz http://www.wafu.ne.jp/~daisuke/DateTime-Event-Lunar-0.01.tar.gz I also plan to create Astro::Event::SolarTerm, which will allow me to partition things nicely within my planned DT::C::Chinese and DT::C::Japanese. --d
Re: [RFC] Astro:: modules
How common is Common? Remember there is stuff like Astro::FITS::CFITSIO (also a good example of why C interfaces suck in perl) under that namespace. CC uses these functions throughout both solar and lunar calculations: julian_centuries nutation obliquity aberration The rest of the stuff involves converting datetime based on location, ephemeris correction, etc. I'm not sure where they would go: # things I think DateTime already handles (I just used CC's # algorithms straight from th book for now): standard_from_universal() universal_from_standard() standard_from_local() local_from_standard() universal_from_local() local_from_universal() # requires ephemeris correction universal_from_dynamical() dynamical_from_universal() # miscellaneous rata_die() - just return DT at 1/1/1 binary_search() search_next() local_from_apparent() equation_of_time() ephemeris_correction() # miscellaneous constants RD_MOMENT_1900_JAN_1 RD_MOMENT_1810_JAN_1 RD_MOMENT_J2000 MEAN_TROPICAL_YEAR MEAN_SYNODIC_MONTH I've tentatively separated out the mathematical stuff out to Astro::CalcUtils (eek, there's *got* to be a better naming). This involves things like polynomial(), angle(), sin_deg()/cos_deg() (trignometric calculations based on degrees). I've also removed Astro::BigFloat in favor of functions in above mentioned Astro::CalcUtils, currently (tentatively) called: bigfloat() bf_downgrade() to handle creation of Math::BigFloat objects (which can be toggled on/off to just return the original value) and downgrade to simple scalars. Astro::Earth::Location - simple structure to store latitude/longitude, etc. Do you know how accurate the algorithm is? Our local guru has a 308 term polynomial. :) Hmm? this was just to store position. No accuracy involved. I can't much speak for the accuracy of CC's algorithms, but seeing the error margin I would use it for datetime calculation, but not for rocket science. --d
DateTime from Rata Die?
I was trying to fool around with some calculations from Calendrical Calculations -- one of the tables in there shows values corresponding to Rata Die dates, and I was trying to see if DateTime supported creating DateTime objects from Rata Die values... I didn't see one, so I guess it doesn't. Is this something that can be implemented? Is there a workaround? --d
Re: DateTime from Rata Die?
Bah, answering my question... my $rata_die = DateTime-new(year = 1, month = 1, day = 1); my $from_rd = $rata_die + DateTime::Duration-new(days = $rd_days); --d I was trying to fool around with some calculations from Calendrical Calculations -- one of the tables in there shows values corresponding to Rata Die dates, and I was trying to see if DateTime supported creating DateTime objects from Rata Die values... I didn't see one, so I guess it doesn't. Is this something that can be implemented? Is there a workaround? --d
[Kinda OT] Could somebody double check this?
Hi, dt-ers.
I've been lurking on this list for some time now, and so far I
understand that while a few people have attempted, nobody has come up
with a lunar, solar, or lunisolar calenders (at least I don't remember
seeing it on this list). And so I was just fooling around with some code
to see if I can at least start creating some of the basic building
blocks for it.
# And if somebody already has implemented this, please let me know so
# I don't waste time ;)
My first stab at it was implementing the function to get the solar
longitude at time t, from [1] p.182. I've done it, and I'm rather proud
of the fact that I actually took the time to understand all this with no
prior knowledge of astronomical calculations, but the thing is, the
results are a bit off:
[EMAIL PROTECTED] lib]$ perl test.pl
R.D. | Solar Longitude | Solar Longitude (from table) |
-214193 | 119.964425 | 119.474975
-61387 | 254.767876 | 254.252390
25469 | 181.939866 | 181.435260
49217 | 189.168174 | 188.662093
171307 | 289.601843 | 289.089403
210155 | 59.601590 | 59.119357
253427 | 228.828880 | 228.316498
[EMAIL PROTECTED] lib]$
The numbers are consistently off by 0.5 degrees or so. eek.
This must be something so stupid in my code, but I've been looking at
the code for way too long. If anybody notices anything wrong, I would
appreciate it. A lot.
I have two files attatched. Astro::Sun is the module that implements the
logic, and test.pl generates the partial table from [1] p.400 (errata 285).
To whomever that might take a look at this code, I thank you very much
in advance.
--d
P.S. please don't bother too much with the module naming. That's just
temporary...
[1] Edward M. Reingold, Nachum Dershowitz
Calendrical Calculations (Millenium Edition), 2nd ed.
Cambridge University Press, Cambridge, UK 2002
# REFERENCES:
# [1] Edward M. Reingold, Nachum Dershowitz
#Calendrical Calculations (Millenium Edition), 2nd ed.
# Cambridge University Press, Cambridge, UK 2002
package Astro::Sun;
use strict;
use DateTime;
use Math::Trig qw(deg2rad);
# I got the following from (DateTime-new(...)-utc_rd_values)[0]
use constant RD_1900_JAN_1 = 693596;
use constant RD_1810_JAN_1 = 660724;
use constant RD_MOMENT_J2000 = 730120.5;
# [1] Table 12.1 p.183 (zero-padded to align veritcally)
use constant SOLAR_LONGITUDE_ARGS = [
# X Y Z
# left side of table 12.1
[ 403406, 270.54861, 0.9287892 ],
[ 119433, 63.91854, 35999.4089666 ],
[ 3891, 317.84300, 71998.2026100 ],
[ 1721, 240.05200, 36000.3572600 ],
[350, 247.23000, 32964.4678000 ],
[314, 297.82000, 445267.1117000 ],
[242, 166.79000, 3.1008000 ],
[158, 3.5,-19.9739000 ],
[129, 182.95000, 9038.0293000 ],
[ 99, 29.8, 33718.148 ],
[ 86, 249.2, -2280.773 ],
[ 72, 257.8, 31556.493 ],
[ 64, 69.9, 9037.750 ],
[ 38, 197.1, -.176 ],
[ 32, 65.3, 67555.316 ],
[ 28, 341.5, -4561.540 ],
[ 27, 98.5, 1221.655 ],
[ 24, 110.0, 31437.369 ],
[ 21, 342.6, -31931.757 ],
[ 18, 256.1, 1221.999 ],
[ 14, 242.9, -4442.039 ],
[ 13, 151.8,119.066 ],
[ 12, 53.3, -4.578 ],
[ 10, 205.7,-39.127 ],
[ 10, 146.1, 90073.778 ],
# right side of table 12.1
[ 195207, 340.19128, 35999.1376958 ],
[ 112392, 331.26220, 35998.7287385 ],
[ 2819, 86.63100, 71998.4403000 ],
[660, 310.26000, 71997.4812000 ],
[334, 260.87000,-19.441 ],
[268, 343.14000, 45036.884 ],
[234, 81.53000, 22518.4434000 ],
[132, 132.75000, 65928.9345000 ],
[114, 162.03000, 3034.7684000 ],
[ 93, 266.4, 3034.448 ],
[ 78, 157.6, 29929.992 ],
[ 68, 185.1,149.588 ],
[ 46, 8.0, 107997.405 ],
[ 37, 250.4,151.771 ],
[ 29, 162.7, 31556.080 ],
[ 27, 291.6, 107996.706 ],
[ 25, 146.7, 62894.167 ],
[ 21, 5.2, 14578.298 ],
[ 20, 230.9, 34777.243 ],
[ 17, 45.3, 62894.511 ],
[ 13, 115.2, 107997.909 ],
[ 13, 285.3, 16859.071 ],
[ 10, 126.6, 26895.292 ],
[ 10, 85.9, 12297.536 ]
];
# [1] p.19
sub _dt_to_moment
{
my $dt = shift;
my($rd, $seconds) = $dt-utc_rd_values;
($rd + $seconds / (24 * 3600));
}
# [1] p172
sub _dynamical_moment_from_dt
{
my $dt = shift;
_dt_to_moment($dt) + ephemeris_correction($dt);
}
# [1] p171 + errata 158
sub ephemeris_correction
{
my $dt = shift;
# we need a gregorian calendar, so make sure $dt is just 'DateTime'
$dt =
Re: What should a business module implement?
This snippet just blew me away. That is just... beautiful.
--d
Ben Bennett wrote:
Is that a generic business calculation or just an application of sets?
I think the latter. You can just make a set representing the
intersection of mondays (or weekdays) and Dec. 31sts. Then iterate
over it (using the restricted time range) to find the solution.
--
use strict;
use DateTime;
use DateTime::Event::Recurrence;
my $dec32 = DateTime::Event::Recurrence-yearly
(months = 12, days = 31);
my $mondays = DateTime::Event::Recurrence-weekly
(days = 1);
my $s = $dec32-intersection($mondays);
my $i = $s-iterator(start = DateTime-new(year = 2000),
end = DateTime-new(year = 2008));
while (my $d = $i-next) {
printf %s - %s\n, $d-day_name(), $d-datetime;
}
--
Prints:
--
Monday - 2001-12-31T00:00:00
Monday - 2007-12-31T00:00:00
--
-ben
On Tue, Jun 17, 2003 at 01:39:00PM -1000, Joshua Hoblitt wrote:
What if I wanted to know inside a range of years which had a December 31st that was on a Monday (or on a weekday)?
-J
--
Re: [ANNOUNCE] DateTime-Calendar-Japanese 0.01 and DateTime-Format-Japanese 0.01
Well, what you made works, but I think it's somewhat missing the point. Yeah, I had that nagging feeling all along ;) good thing you took a look. But your object does not actually represent the Japanese calendar. What I'm getting at is that given a DateTime::Calendar::Japanese object, I'd expect a method like -year to return the year as it is numbered in the _Japanese_ calendar, not in the Gregorian calendar! So Japan uses the Gregorian calendar, except notations differ. This was the original reason why I dumped this era type of thing into the Format:: module. I'm not sure what else I would put in a Japanese calendar? (Now that I know Miyagawa-san is in this list, he may be able to help me here :) So for example, my $cal = DT::Calendar::Japanese-new(); print $cal-year, \n; What should it do: return the year in Japanese characters? or, I guess it could be something like Heisei 15... hmm. This is how the DT::Calendar::Japanese class should work. In addition, you'll also want methods like -era, -regime, possibly -kigen, and methods to return the major and minor solar terms. Is solar term = koyomi? And when you say kigen, what are we talking about... Hmm, so is DT::Calendar::Japanese supposed to do things like $cal-year; # Heisei 15 $cal-month; # Nyo-tuki $cal-day; # 2 day (in Japanese) Is that what you're saying? I just thought that would go to the formatter. Or, are we talking about the Lunar Year system? If you do want to do this, let's collaborate, because I want to create DateTime::Calendar::Chinese, and they share a lot of core calculations. We might be able to put these in some sort of DateTime::Algorithm::ChineseJapanese module that we could both include as a prereq. That's cool! I'm just still a bit confused :) --d
[ANNOUNCE] DateTime-Calendar-Japanese 0.01 and DateTime-Format-Japanese 0.01
I've hacked together DT::Calendar::Japanese and DT::Format::Japanese. Is there anybody on this list that can use Japanese on his machine? Features: DT::Calendar::Japanese: - support for all Japanese eras since 645 A.D, including 1331 and 1392 where there were two regimes claiming their own eras DT::Format::Japanese: - support kanji, zenkaku arabic, and ascii arabic numbers - support eras I'm waiting for my PAUSE ID, but meanwhile, they are up here: http://www.wafu.ne.jp/~daisuke/DateTime-Calendar-Japanese-0.01.tar.gz http://www.wafu.ne.jp/~daisuke/DateTime-Format-Japanese-0.01.tar.gz Pls let me know if I did anything glaringly wrong. --d
Re: RFC DateTime::Calendar::French_Rev
There is absolutely no reason you should feel compelled to offer the full DateTime.pm interface. Offer what makes sense for _your_ calendar. The Julian calendar is actually a really _bad_ example for other calendar module authors, because it's API is almost identical to the Gregorian calendar (DateTime.pm). Most other calendars will have a greater departure from the DateTime.pm API. So what about the Calendar that I just wrote: It gives you Japanese eras, and that's pretty much the only additional feature over DateTime. Since nothing really changes in the way dates or time are counted, I just thought that it would be easier if it just inherited from DateTime instead of implementing each method like the Julian Calendar. Was that a bad thing to do? --d
DateTime::Language
(BHi, (B (BI just subscribed to this list after seeing the article in use.perl.org. (BI apologize if this topic has been discussed before... (B (BI got the CVS version of DateTime.pm, and I noticed there wasn't a (Bsingle Asian DateTime::Language module. So I thought I might do a quick (Bhack and get you guys the Japanese version... (B (BThen I noticed that DateTime::Language only has attributes for month (Bnames, day names, and am/pm. What about time representation? And also, (Bthere's the suffix characters that one might use in Japanese.. (B (BE.g (sorry if you can't read Japanese characters). (B (B western notation: 2003-12-31 14:32:24 (B Japanese notation: 2003$BG/(B12$B7n(B31$BF|(B 14$B;~(B32$BJ,(B24$BIC(B (B (or even: $BFs!;!;;0G/==Fs7n;0==0lF|(B $B==;M;~;0==FsJ,Fs;MIC(B) (B (BFor those of you who can't read the above, basically each component is (Bfollowed by a character that denotes what the previous component stands (Bfor like this: (B (B 2003(year)12(month)31(days) 14(hours)32(minutes)24(seconds) (B (BI suspect that same goes for some Asian languages. (B (BHas there been any thoughts put into this? (B (B--d
Re: DateTime::Language
They're special because they're _really_ simple, and they're _really_ commonly used ;) That's about it, and yes, it is not consistent, but it's relatively convenient. To put it another way, what you're discussing is a _locale_ issue (it's how dates are shown in your area) as opposed to a _language_ issue (the _names_ of things, regardless of display). Fair enough. So would you suggest there be a DateTime::Language::* and DateTime::Format::* for each non-latin1 language that DateTime may want to handle? Furthermore, what would you suggest for somebody who wants to do a strftime-like thing, but say, with Japanese numbers instead of Arabic. Is that a Language module or a Format module? I'm asking this because if I *really* wanted to add Japanese support to DateTime::*, there'd be at least 3 diffrent notations for month names, and 3 different notations for time. I'm kind of unsure where each of these should/would go. --d
