Re: hires DateTime-from_epoch( epoch = ... ) values

Since nobody has commented on this patch does that mean everybody agrees that it's a good idea? :) -J -- On Mon, Jul 25, 2005 at 04:10:53PM -1000, Joshua Hoblitt wrote: Hi Folks, I stumbled across a limited precision issue while working on DateTime::Format::DateParse. One of 'epoch' test

[announce] DateTime::Format::ISO8601 0.0403

The 'Al might be a whiner' release. Released to CPAN. Changes since 0.0402 - update doc format - tidy Build.PL - auto-generate Makefile.PL - change set_base_datetime() to use DT's overloaded = instead of -compare() - tidy test sources and reduce runtime Cheers, -J

Store DateTime::Event::Cron objects ?

Hi I'm using the nice DateTime::Event::Cron module. I do want to save the cron schedules in a database. The easiest way would be to stringify and destringify the objects. Is this possible?

Re: Store DateTime::Event::Cron objects ?

I'm using the nice DateTime::Event::Cron module. I do want to save the cron schedules in a database. The easiest way would be to stringify and destringify the objects. Is this possible? The same question goes for DateTime::Set objects. Can they be made persistent?

Re: hires DateTime-from_epoch( epoch = ... ) values

On Mon, 25 Jul 2005, Joshua Hoblitt wrote: a) do nothing... nobody else seems to have noticed b) document the limited precision issue c) change the API to some awful Fortranish a part + b part to preserve precision d) turn the epoch parameter into a Math::BigFloat so a high resolution 'string'

Re: Store DateTime::Event::Cron objects ?

Hello Kaare, I'm using the nice DateTime::Event::Cron module. I do want to save the cron schedules in a database. The easiest way would be to stringify and destringify the objects. Is this possible? Since, in essence, DT::E::Cron is designed to convert cron strings into datetime recurrences,

Re: hires DateTime-from_epoch( epoch = ... ) values

On 8/8/05, Dave Rolsky [EMAIL PROTECTED] wrote: Does anyone object to adding Math::BigFloat as a prereq? What are the performance/memory implications? I don't object to the prereq, but I would like to know if we're in for any new speed/bloat issues. (I only really care about per-object

Re: hires DateTime-from_epoch( epoch = ... ) values

On Mon, 8 Aug 2005, John Siracusa wrote: On 8/8/05, Dave Rolsky [EMAIL PROTECTED] wrote: Does anyone object to adding Math::BigFloat as a prereq? What are the performance/memory implications? I don't object to the prereq, but I would like to know if we're in for any new speed/bloat issues.

RE: hires DateTime-from_epoch( epoch = ... ) values

On Mon, 25 Jul 2005, Joshua Hoblitt wrote: a) do nothing... nobody else seems to have noticed b) document the limited precision issue c) change the API to some awful Fortranish a part + b part to preserve precision d) turn the epoch parameter into a Math::BigFloat so a high resolution

Re: Store DateTime::Event::Cron objects ?

Since, in essence, DT::E::Cron is designed to convert cron strings into datetime recurrences, why not use the original cron specification as the The not-so-easy part is my small addition: The same question goes for DateTime::Set objects. Can they be made persistent?

Re: Store DateTime::Event::Cron objects ?

Quoting Kaare Rasmussen [EMAIL PROTECTED]: The same question goes for DateTime::Set objects. Can they be made persistent? Flavio was working on something along these lines, though I'm not sure of the current status. Check out the following thread:

Re: Store DateTime::Event::Cron objects ?

2005/8/8, Matt Sisk [EMAIL PROTECTED]: Quoting Kaare Rasmussen [EMAIL PROTECTED]: The same question goes for DateTime::Set objects. Can they be made persistent? Flavio was working on something along these lines It actually worked, but the performance was too bad for complex sets. The

Re: hires DateTime-from_epoch( epoch = ... ) values

On Mon, Aug 08, 2005 at 09:31:10AM -0500, Dave Rolsky wrote: On Mon, 25 Jul 2005, Joshua Hoblitt wrote: a) do nothing... nobody else seems to have noticed b) document the limited precision issue c) change the API to some awful Fortranish a part + b part to preserve precision d) turn the