Re: DateTime.pm on a Diet
Le 5 juil. 05 à 15:15, John Siracusa a écrit : On 7/5/05 7:04 AM, Eric Cholet wrote: A while ago we did some profiling of an app that uses DateTime extensively and found out that most of the time is spent in Params::Validate. I understand this is somewhat of a religious issue, but in this case it's a net loss for us: the params have been validated zillions of times, and we lose performance in production. I would love a DateTime sans param validation. Have you tried turning off the validation by setting the PERL_NO_VALIDATION environment variable? John, thanks for the pointer. I see this is documented in Params::Validate. I'd never thought of looking in Params::Validate docs to find out how to disable DateTime's use of it. It might be useful to include a pointer to this feature in DateTime's docs. -- Eric Cholet
Re: DateTime.pm on a Diet
Le 4 juil. 05 à 19:47, Dave Rolsky a écrit : Well, I'd take Sam's message with a grain of salt. I use it in lots of projects, and I know it's being used by lots of other people for lots of things. The idea that it's too slow is bogus. It might be too slow/bulky if you're creating thousands or hundreds of thousands of objects at once, but even then I wonder if it is. A while ago we did some profiling of an app that uses DateTime extensively and found out that most of the time is spent in Params::Validate. I understand this is somewhat of a religious issue, but in this case it's a net loss for us: the params have been validated zillions of times, and we lose performance in production. I would love a DateTime sans param validation. -- Eric Cholet
Re: RFC: Date::Iterator
Le 19 déc. 03, à 13:34, Marco Marongiu a écrit : SEE ALSO The wonderful Date::Calc module This needs to be replaced with: SEE ALSO The wonderful DateTime module Cheers, -- Eric Cholet
Re: More flexibly subtract/difference methods
Matt Sisk wrote: Dave Rolsky wrote: Currently, the default when subtracting datetimes is to break down the duration into multiple parts, months, days, minutes, seconds, and nanoseconds. From the months piece we can derive years, and from the days piece we can derive weeks. Rick Measham responded: Except, as Flavio points out, for non-gregorian calendars. Perhaps the Calendar classes can offer 'unit conversion' methods suitable for their particular idiom. Datetime could utilize these conversion methods when found, otherwise default to 'Gregorian' style calculations. Yeah, let not the Aztec-Revolutionnary calendar users stop us from finally having number of a days between two days that us in the real world need, hopefully in DateTime without the need for an extra module. (insert appropriate smiley here). -- Eric Cholet
Re: ANNOUNCE: DateTime 0.14
It isn't clear from the Changes files that the switch from Language to Locale also means that day and month names are now returned in utf8 instead of latin1, at least that's what I see when using 'fr'. Am I correct in assuming that this change cames about in 0.14? (I have the self inflicted issue of having code that must work with DateTime 0.10, 0.13 and 0.14) -- Eric Cholet
Re: set_time_zone problem
--On Wednesday, March 26, 2003 00:34:18 -0600 Dave Rolsky [EMAIL PROTECTED] wrote: On Mon, 24 Mar 2003, Eric Cholet wrote: my $date = DateTime-now; $date-set_time_zone( 'Pacific/Tarawa' ); results in: Invalid local time for date -00-00T00:00:00 at /Library/Perl/DateTime/TimeZone.pm line 142. This is DateTime 0.07 and DateTime::TimeZone 0.09. I do not see this behavior with most time zones I've tried, I just stumbled upon it when selecting an exotic timezone. Actually, this is a bug that affect _all_ timezones that don't have DST changes! Eek, look for a new DT:::TimeZone release very soon ;) Dave, I confirm that DT::TZ 0.11 fixes that problem. On behalf of my Tarawan users, thanks! -- Eric Cholet
DateTime languages
I want to use the DateTime language stuff, mainly so that I can use DateTime's strftime instead of my own cooked up one, but I find it difficult to integrate with my applications because of the non standard English language names it uses, instead of ISO language codes such as ISO639. I can build up a mapping fr = French, en = English, but shouldn't DateTime rather use ISO language codes directly? -- Eric Cholet
