in reply to Year /^\d+$/ bug!

I've run into this a couple of different times in my work and all I can tell is that both are correct...depending on the business needs at hand.

For example, a billing statement often, by law, needs to provide a set number of days. When implementing that sort of system, you find out what the client's accountants use when balancing the books and go from there.

On the other hand, a calender is generally looking for something to the effect of Dec 30 to Jan 30.

To handle the "Feb 30" problem, I usually decrement the previous result by one day until I have a valid date. The next search then becomes Mar 28 (or 29, depending on the year).

If you're not completely comfortable forcing either approach, then use gaspodethewonderdog's idea: implement both and then let the end user/developer choose which they prefer via a property or configuration setting.

--f

Replies are listed 'Best First'.
Re: Re: Year /^\d+$/ bug!
by Blue (Hermit) on Nov 30, 2000 at 19:57 UTC
    For example, a billing statement often, by law, needs to provide a set number of days.

    I think that is the point - it's all the granularity you are working with. If you are dealing with days, then adding 30 days to Jan 31st should bring you into March. If you are dealing with months, then adding 1 month to Jan 31st should bring up into Feburary.

    In my opinion, that is the 'correct' default behavior for a module where you aren't sure what the end developer will need, perhaps generating warnings if you can't do an exact mapping (Jan 31st -> Feb 31st).

    =Blue
    ...you might be eaten by a grue...

[reply]

In Section Meditations