On Mon, Feb 6, 2017 at 2:47 AM, Rob Stradling via Public < [email protected]> wrote:
> I agree with Peter that it would make much more sense to define maximum > validity periods in terms of numbers of days, not numbers of months. I'm happy to accommodate this with Ballot 185/186, I suppose I'm somewhat surprised by it. That is, I would have thought it intuitive that: July 31 -> Aug 31 = 1 month (31 days) Jan 1 -> Feb 1 = 1 month (31 days) Similarly, I would have thought it generally uncontroversial that Jan 31 -> March 3 != 1 month (despite being 31 days) May 31 -> July 1 != 1 month (despite being 31 days) If we thus apply the same logic, we determine that Jan 31 -> Feb 28 (or 29) == 1 month May 31 -> June 30 == 1 month However, this does mean that the definition of "How many days in 13 months" varies depending on your start day, for the aforementioned reasons, and that variability is no doubt something that some might have concern with. For example, this also means that Feb 28 (or 29) -> March 28 (or 29) == 1 month I have difficulty with understanding the "it's easier for computers" argument, since any general date-aware application can apply a rather simple rule - the difference in years * 12, the difference in months, and counting any negative difference in days as 'another month'. As Rob mentioned on the issue, this approach is at least consistent with Oracle's implementation, and certainly consistent with how we (Google) have interpreted this requirement. However, because there's any interpretation involved at all, I'm happy to defer to days, with the clarification that any difference in the time period as well becomes considered a full day as well That is Jan 1 00:00:00 -> Jan 2 00:00:00 == 1 day Jan 1 00:00:00 -> Jan 2 00:00:01 > 1 day (And luckily, the same doesn't have to be said about fractional microseconds)
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
