Re: DateTime.pm on a Diet
Dave Rolsky wrote: It has a pretty different API, in that it's new() constructor accepts anything without validation. I suppose it could check for extra args and call DateTime::Fat-new() if needed. Can we split the existing new() into validation vs. object creation and share it between the two equally (no, I haven't looked at the source)? Thus, the lightweight new() could validate by default, but offer a quick no_validate = 1 option for the people creating objects out of databases (prevalidated). It may be once that you are slinging lightweight objects around most of the time, the performance drain due to validation won't be quite as noticible. I think that'd be a possibility, but it'd have to pass the DateTime.pm test suite in that case. That's certainly where I was considering starting (with the test suite). It might also be a good experiment to see where the performance issues really are. John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: DateTime.pm on a Diet
On Thu, 7 Jul 2005, Rick Measham wrote: Dave Rolsky wrote: It has a pretty different API, in that it's new() constructor accepts anything without validation. I suppose it could check for extra args and call DateTime::Fat-new() if needed. I think that'd be a possibility, but it'd have to pass the DateTime.pm test suite in that case. We'd need to bring complete validation back in though. Otherwise your object dies unexpectedly later on: $dt = DateTime::Diet-new( year = 2004, month = 232 ); print $dt-year; #2004 print $dt-month; #232 print $dt-monthname; # DIE: Illegal value passed to DateTime::new Yeah, this occurred to me after I wrote that. Having these sorts of delayed errors is very bad and surprising for users. Rick's code is well suited to instances where you have data that you've already checked, but not so good for general purpose usage. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Arbitrary Date Parsing [Was: Re: Date::Parse (Time::Local?) choking on years between 1956-1938 and wrong below, on FC4/5.8.6]
Nicholas Clark wrote: On Wed, Jul 06, 2005 at 12:20:50AM -0400, Ronald J Kimball wrote: Fortunately, you don't really need to convert your dates into time values, just so you can convert them back into dates. Some modules which may be more useful in this case include Date::Manip, Date::Calc, and POSIX (for strftime). I believe that the DateTime family of modules might be of most use here. They aren't constrained by underlying localtime implementations. DateTime is on CPAN, details on the DateTime project are at http://datetime.perl.org/ Nicholas Clark I moved this thread over from perl.perl5.porters (in case anyone wants to follow it back to the original post) But basically my needs come down to being able to parse arbitrary dates. DateTime::Format::HTTP (aka HTTP::Date) for obvious reasons, barfs on certain well-known date formats used by humans, so is not an adequate substitute for Date::Parse. I'm sort of surprised that there is no equivalent DateTime-using module that would mirror the capabilities of Date::Parse. Dave, Have you talked with Graham Barr at all about merging the arbitrary-date-parsing capabilities (of Date::Parse) into the DateTime family tree?
Re: DateTime.pm on a Diet
On 7/7/05 12:12 AM, Rick Measham wrote: Dave Rolsky wrote: DateTime::Shim DateTime::Trampoline DateTime::ThinShim DateTime::Proxy DateTime::Diet - not awful but a little cute, methinks ;) Of the above, I still like DT:Diet. If you want something less cute/more serious how about: DateTime::FastConstructor The others listed above don't seems to convey the purpose of the module. I'll throw a few names out: DateTime::Delayed DateTime::AutoLoaded DateTime::LazyInit -John
Re: Arbitrary Date Parsing [Was: Re: Date::Parse (Time::Local?) choking on years between 1956-1938 and wrong below, on FC4/5.8.6]
Scott R. Godin wrote: I'm sort of surprised that there is no equivalent DateTime-using module that would mirror the capabilities of Date::Parse. Dave, Have you talked with Graham Barr at all about merging the arbitrary-date-parsing capabilities (of Date::Parse) into the DateTime family tree? G'day Scott, It's been discussed before, and the main reason is below. There's just no way to properly parse a datetime. You can make 'best guesses'. But you should probably use something else to make your guesses, then offer them to the user to pick which they meant. DateTime prides itself on being accurate and predictable and should never produce unexpected results. That being said, there would certainly be room for a DateTime::Format::Guess module that took strings and attempted to guess what the string represented. Just be prepared for a lot of .. erm .. 'help' from this list describing the various preferences for guessing that would need to be included. I think Graham has even mentioned something about it himself, though that could be complete tish. [At one stage I was a fair way through a module that could get down to finding the date in text such as She promised she'd be there by five past midday on the first Monday in April, until I realised that it was a fun exercise but not much use.] Cheers! Rick Measham parse(04.05.12) - May 4th, 1912 - May 4th, 2012 - April 5th, 1912 - April 5th, 2012 - May 12, 1904 - May 12, 2004 - 4:05:12 AM - 16:05:12 (4:05:12 PM)
