Hello, On Sat, Mar 22, 2003 at 08:02:22PM -0500, [EMAIL PROTECTED] wrote: > > My question is .. should they return midnight? > > If its noon on the 4th > > July and we ask for 'next' or 'set' do we > > include the current? > > Probably not. > > agree. > > > But if we return midnight, does > > 'previous' return the > > current? Really shouldn't. > > agree. > - next() returns ">", > - prev() returns "<". > - is() returns yes-no (???)
I'd like to share a different approach. How about that: (1) "Calendrical events" I am talking about are arbitrary dates (days!) with some notion of recurrence, like "Monday", "first of month", "July 4th", "Easter Sunday". (2) There is one method (per event) which takes a DateTime object and a relation operator, advancing the DateTime object forward or backwards to the event, in one of four ways: DateTime::Event::FourthJuly::adjust($d, '>='); # same or next DateTime::Event::FourthJuly::adjust($d, '>'); # next DateTime::Event::FourthJuly::adjust($d, '<'); # previous DateTime::Event::FourthJuly::adjust($d, '<='); # previous or same (3) Relations and changes are based on day granularity, so that hours, minutes and seconds in general remain unchanged. In case a daylight savings time border is crossed the same behaviour as with DateTime::set(year => ..., month => ..., day => ...) applies. (4) Events occuring exactly once per year or per month also have a method which does not maintain a certain relation but simply keeps the year (and month, if appropriate) the same: DateTime::Event::FourthJuly::set($d); # keeps year End of proposal. One thing I am not yet happy with is the level of object orientation, however. I would like to see something like: $d = DateTime->new(year => 2008)->FourthJuly; set $d to midnight, July 4th, 2008. Would that make sense? -Martin
