Re: Scheduling/dates design -- iCal + RMDBS? Or...?

iCal format in DB fields? I guess you are not scheduling past dates, and I guess (I might be wrong) your dates don't survive the 32 Bit timestamp overflow. I'd store a timestamp (as GMT, seconds since epoch) and an offset in the DB (for duration) and then (depending of the scope of the application) some attributes, like timezone, DST begin/end etc and implement all conversions with a CPAN module (myriads of Date stuff modules, pick one.)

But iCal format in DB fields? *shudder* I guess your app would spend lotsa time in some conversion sub.

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Comment on Re: Scheduling/dates design -- iCal + RMDBS? Or...?

Replies are listed 'Best First'.
Re^2: Scheduling/dates design -- iCal + RMDBS? Or...? by Your Mother (Archbishop) on Nov 24, 2007 at 02:55 UTC
I shudder as well. Just having a hard time thinking of how to best do parts of this (especially frequency) without riding a scheduling grammar. Crontab grammar is fairly powerful too...	[reply]