Date/time feature ambiguity about exhibit3 HOT 4 CLOSED

Re: roundDown.

The roundDown method was treating DAY and WEEK as an interval of one regardless of the argument, rounding times down to 0 for the day and dates to the beginning of the week (which could be specified as an argument) for WEEK. I think perhaps we should go ahead and correct the code to follow more rational interpretations, like you've already done for day. Your interpretation of week makes sense.

We should perhaps add a time zeroing function to the library to accomplish what roundDown DAY did, like the private clearInDay function. I'm not sure we need a replacement for the original WEEK code, I guess we can add it in to the library if ever we do.

from exhibit3.

re: roundUp.

Your interpretation of its intended results is fine, but the implementation itself is naïve. The pieces up through DAY passed fine for me because they are strictly correct, but when it gets to month, the numbers are wrong (month is defined as 31 days long), so adding 10 'months' becomes problematic in two ways, first because it's adding 310 days instead of ten calendar months, second because it's adding ten months to 0 where 0 means January 1, which brings it into November instead of October. The same type of naïve issue appears to be at work with all date units from month and beyond.

from exhibit3.

Re: ISO 8601

No, let's not bother with fractional times. It's apparently been entirely unnecessary up until now. Let's add it when and if we need it, but I don't think we'll need to.

from exhibit3.

This bug is too stale for me to remember details, but it seems like modifying the week rounding code needs to take place, and the code for rounding up for durations longer than days needs to be fixed to stop being naïve.

from exhibit3.