Re: MySQL input formats [was Re: ANNOUNCE: DateTime 0.08]
On Thu, 20 Mar 2003, Joshua Hoblitt wrote: Actually, I think maybe a doc patch is in order instead. The goal of the parse_* methods is to parse things returned _by MySQL_ as a result of queries, not to parse any format that MySQL itself might accept. Aww, thats not the asumption I was working under. Are you sure that no one would want to parse the _all_ the formats MySQL accepts? Perhaps a relaxed flag is in order? I honestly don't see the point. I'm not trying to write code for use by MySQL itself ;) I just want to provide something that makes interfacing with MySQL easier. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: ANNOUNCE: Date-ICal 2.06
On Fri, 21 Mar 2003, fglock wrote: All methods are DateTime wrappers; all tests pass. - Thanks to Dave Rolsky for helping with bugs! - The functions jd2greg(), greg2jd() are still native. You should use _rd2ymd and _ymd2rd. These are much faster cause they're written in C in DateTime.xs. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::Set API - constructors
On Fri, 21 Mar 2003, fglock wrote: Dave Rolsky wrote: I think the API needs to be simple and encourage simplicity in its use, because this is a complicated area. Ok. This one is rather simple: $dt_spanset = $dt_set-to_SpanSet( duration = $dt_one_month ); Converts this DT::Set 2002-01-01 , 2003-01-01 to this DT::SpanSet [ 2002-01-01 , 2002-02-01 ) , [ 2003-01-01 , 2003-02-01 ) I like this. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: ANNOUNCE: Date-ICal 2.06
So is the DateTime suite going to be completely dependent on XS code? If so, I have at least one app that will need to stick with Date::PCalc or some pure perl solution. BTW, I enjoyed your recent perl.com article on dates, but wish you had mentioned which datetime modules were pure perl and which relied on XS code. Thanks, Wes Sheldahl Dave Rolsky [EMAIL PROTECTED] on 03/21/2003 12:23:32 PM To:fglock [EMAIL PROTECTED] cc:[EMAIL PROTECTED] Subject:Re: ANNOUNCE: Date-ICal 2.06 On Fri, 21 Mar 2003, fglock wrote: All methods are DateTime wrappers; all tests pass. - Thanks to Dave Rolsky for helping with bugs! - The functions jd2greg(), greg2jd() are still native. You should use _rd2ymd and _ymd2rd. These are much faster cause they're written in C in DateTime.xs. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: XS in DateTime.pm
On Fri, 21 Mar 2003 [EMAIL PROTECTED] wrote: So is the DateTime suite going to be completely dependent on XS code? If so, I have at least one app that will need to stick with Date::PCalc or some pure perl solution. I suppose I could include a pure Perl solution. What is your barrier to using XS? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: ANNOUNCE: Date-ICal 2.06
Dave Rolsky wrote: On Fri, 21 Mar 2003, fglock wrote: All methods are DateTime wrappers; all tests pass. - Thanks to Dave Rolsky for helping with bugs! - The functions jd2greg(), greg2jd() are still native. You should use _rd2ymd and _ymd2rd. These are much faster cause they're written in C in DateTime.xs. Aren't rd and jd different functions? I mean, this is the API, not internal functions. They aren't even used by the module itself. - Flavio S. Glock
Re: XS in DateTime.pm
Dave Rolsky wrote: I suppose I could include a pure Perl solution. What is your barrier to using XS? That's something I'd like too. I could test my code on Windows, without having to wait until someone compiles it for me. - Flavio S. Glock
Re: ANNOUNCE: Date-ICal 2.06
On Fri, 21 Mar 2003, fglock wrote: Dave Rolsky wrote: On Fri, 21 Mar 2003, fglock wrote: All methods are DateTime wrappers; all tests pass. - Thanks to Dave Rolsky for helping with bugs! - The functions jd2greg(), greg2jd() are still native. You should use _rd2ymd and _ymd2rd. These are much faster cause they're written in C in DateTime.xs. Aren't rd and jd different functions? I mean, this is the API, not internal functions. They aren't even used by the module itself. The thing is that when Date::ICal says jd there it's lying because it really produces Rata Die days! In fact, those functions are the same as what DateTime.pm uses, I just recoded them in C. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: XS in DateTime.pm
On Fri, 21 Mar 2003, fglock wrote: Dave Rolsky wrote: I suppose I could include a pure Perl solution. What is your barrier to using XS? That's something I'd like too. I could test my code on Windows, without having to wait until someone compiles it for me. Ok, I'll implement this for the next release. It's simple enough since all the code existed in Perl previously. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: Date-ICal 2.07
Dave Rolsky wrote: You should use _rd2ymd and _ymd2rd. These are much faster cause they're written in C in DateTime.xs. ... The thing is that when Date::ICal says jd there it's lying because it really produces Rata Die days! In fact, those functions are the same as what DateTime.pm uses, I just recoded them in C. Done. The tests seem to go slightly faster (5-10%) than Date-ICal 1.72. http://www.ipct.pucrs.br/flavio/perl/Date-ICal-2.07.tar.gz - Flavio S. Glock
Date::ICal to DateTime
Is it ok to have a to_DateTime function in Date::ICal ? $dt = $d_ical-to_DateTime() Such that you can do tricks with non-DateTime modules: use Date::Passover; $dt = passover( 1997 )-to_DateTime; - Flavio S. Glock
Re: MySQL input formats [was Re: ANNOUNCE: DateTime 0.08]
I honestly don't see the point. I'm not trying to write code for use by MySQL itself ;) I just want to provide something that makes interfacing with MySQL easier. I often accept input, modify it some how (offsets, etc), and then pass it on to MySQL. It is totally reasonable to accept the same formats as MySQL itself. Since this is a very minor modification I don't understand your resistance. Cheers, -J
DateTime::Set::Sunrise?
While I know that DateTime::Astro::Sunrise has been released, I wonder if it should not have been DateTime::Set::Sunrise? I figure that it is a set of DateTimes, albeit not like our regular sets (every Monday). If not DateTime::Set::Sunrise, then it should be put wherever we'll put such things as: ::Easter ::Passover ::USElectionDay ::LunarEclipse ::SolarEclipse ::etc... Cheers! Rick There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners
RE: DateTime::Set::Sunrise?
Hi Rick, While I know that DateTime::Astro::Sunrise has been released, I wonder if it should not have been DateTime::Set::Sunrise? Well, it is up to the group. I released this module as a development release SO, it should not be a problem with changing the name. BTW, before posting this module I did ask the group about the name and release version. As far as I am conserned, I am willing to use what the group wants!! I figure that it is a set of DateTimes, albeit not like our regular sets (every Monday). If not DateTime::Set::Sunrise, then it should be put wherever we'll put such things as: ::Easter ::Passover ::USElectionDay ::LunarEclipse ::SolarEclipse ::etc... Cheers! Rick Thanks Rick, Ron Hill
DateTime and Holidays
Hello, up to now, most of the work appears to have gone into the time scale stuff - providing an API to map various date and time representations to each other. I'd like to see another important aspect of calendars (namely the Gregorian calendar) covered in the DateTime framework, too: defining all sorts of holidays. Lots of applications need to tell business days from public holidays, and calendrical displays for humans in fact show holidays by their name. Of course, this needs layers of localization and customization as well as additional basic algorithms (like calculating the date of Easter). Where should all that go? Unfortunately (in my opinion), the DateTime::Calendar namespace seems to have been assigned to alien time scales rather than to whatever a time scale additionally needs to make up a calendar. It might be feasible to separate date calculations (depending on what calendar is used) from nomenclature issues (depending mostly on locales). Ideas, anyone? -Martin
Re: MySQL input formats [was Re: ANNOUNCE: DateTime 0.08]
My general feeling (without looking at the relevant code to closely) is that this should go into a MySQL-specific module. The core should be kept small and fast (I have no use for MySQL dates and speed is important). DateTime::Format::MySQL isn't a MySQL specific module? :)
Re: XS in DateTime.pm
On Fri, 21 Mar 2003, Tim Bunce wrote:
Having transparent failover is handy.
You can wrap the bootstrap call in an eval { }. Then you've got
a few choices, either put the perl versions of the XS subs at the
end after __DATA__ and add use SelfLoader;, or do a require of a
separate module with the perl code. I'd suggest the later, it's
what the DBI uses to load DBI::PurePerl.
That's what I did with Params::Validate when Ilya Martynov re-coded it in
XS.
Another key issue is the need to automatically test both XS and
pure perl versions. The DBI has a cute trick for this. For every
t/*.t file the Makefile.PL writes a t/zz_*.t that just contains:
#!perl -w
$ENV{DBI_PUREPERL}=2;
do 't/test-name-here.t' or warn $!;
die if $@;
exit 0
The env var triggers the DBI to not even try to bootstrap the XS
code but go straight to loading the pure-perl code.
Having this automated has caught countless would-be-bugs as the DBI
and it's test suite has evolved.
Ah, clever. I need to add something like this to Params::Validate as
well.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: DateTime::Set::Sunrise?
On Sat, 22 Mar 2003, Rick Measham wrote: While I know that DateTime::Astro::Sunrise has been released, I wonder if it should not have been DateTime::Set::Sunrise? I figure that it is a set of DateTimes, albeit not like our regular sets (every Monday). If not DateTime::Set::Sunrise, then it should be put wherever we'll put such things as: ::Easter ::Passover ::USElectionDay ::LunarEclipse ::SolarEclipse ::etc... That'd be DateTime::Event. Yeah, I think renaming it as DateTime::Event::Sunrise would best fit my master plan (hah, such as it is). -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
