Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03

Ken Murchison <murch@andrew.cmu.edu> Tue, 03 February 2015 15:02 UTC

Return-Path: <murch@andrew.cmu.edu>
X-Original-To: calsify@ietfa.amsl.com
Delivered-To: calsify@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683191A0377 for <calsify@ietfa.amsl.com>; Tue, 3 Feb 2015 07:02:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.309
X-Spam-Level:
X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUMCu-rNsB_J for <calsify@ietfa.amsl.com>; Tue, 3 Feb 2015 07:02:11 -0800 (PST)
Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F4C41A036E for <calsify@ietf.org>; Tue, 3 Feb 2015 07:02:11 -0800 (PST)
Received: from localhost.localdomain (cpe-76-180-151-43.buffalo.res.rr.com [76.180.151.43]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.8/8.14.8) with ESMTP id t13F21HM001496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Feb 2015 10:02:02 -0500
Message-ID: <54D0E2E9.2030505@andrew.cmu.edu>
Date: Tue, 03 Feb 2015 10:02:01 -0500
From: Ken Murchison <murch@andrew.cmu.edu>
Organization: Carnegie Mellon University
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Cyrus Daboo <cyrus@daboo.name>, Barry Leiba <barryleiba@computer.org>
References: <68FCD7D11F934509267D5915@cyrus.local> <CALaySJKQP9WjRQV2qrgfLiGwj-SQAUCF6RVcQuRrUYNpfqp17A@mail.gmail.com> <7FF77F2FE3390FFD1149E953@cyrus.local> <CALaySJK3RiXXHTq9MC4nwA4c_gZzEVDoWa96MDc7Ue4yDRgbWA@mail.gmail.com> <C80A141CD062EFF630B6D2BB@caldav.corp.apple.com>
In-Reply-To: <C80A141CD062EFF630B6D2BB@caldav.corp.apple.com>
Content-Type: multipart/alternative; boundary="------------030507000303010300080908"
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.3.145118
X-SMTP-Spam-Clean: 27% ( SXL_IP_DYNAMIC 3, BODYTEXTH_SIZE_10000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, REFERENCES 0, __ANY_URI 0, __BAT_BOUNDARY 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_HTML 0, __HAS_MSGID 0, __INT_PROD_LOC 0, __IN_REP_TO 0, __MAL_TELEKOM_URI 0, __MIME_HTML 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __RDNS_POOLED_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0)
X-SMTP-Spam-Score: 27%
X-Scanned-By: MIMEDefang 2.74 on 128.2.105.203
Archived-At: <http://mailarchive.ietf.org/arch/msg/calsify/rw_YCaxbnSnT2-roZCnctGTPmZw>
Cc: Calsify <calsify@ietf.org>
Subject: Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/calsify/>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Feb 2015 15:02:14 -0000

Hi Cyrus,

On 02/03/2015 09:51 AM, Cyrus Daboo wrote:
> Hi Barry,
>
> --On February 2, 2015 at 11:12:14 PM -0500 Barry Leiba 
> <barryleiba@computer.org> wrote:
>
>> Yes... I thought about that as I was sending the last message, but then
>> figured that never happens.  But maybe it can.  I think your version
>> here does cover it.
>
> Actually I have thought some more about it too and come to a slightly 
> different conclusion. I think when a SKIP=FORWARD is used with a leap 
> month, the correct behavior, if the resulting date is invalid, is to 
> keep the (valid) month fixed, and instead change the date to the last 
> day of that month (in effect a SKIP=BACKWARD for the invalid date). I 
> think that makes sense because if my birthday was the last day of a 
> leap month I would probably want to celebrate on the last day of the 
> next month, not the first day of the month after that. Similarly, if 
> SKIP=BACKWARD is used with a leap month, then SKIP=BACKWARD should 
> also be applied to any invalid date that results - the same argument 
> for SKIP=FORWARD being relevant.
>
> So I now have this:
>
> 1. If the date is invalid because the month is not a valid month in the
> correct year, the SKIP is to the next (forward) or previous (backward)
> valid month. If the resulting date is invalid (the day-of-month 
> exceeds the number of days in the specified month) then adjust the 
> day-of-month to the last (valid) value for that month.
>
> 2. Otherwise, if the date is invalid because the day-of-month is not 
> valid for that month, the SKIP is to the next (forward) or previous 
> (backward) valid day.

I was also thinking about birthdays and doing some research.  For the 
case of birthdays on the Hebrew calendar, if we can trust Wikipedia 
<http://en.wikipedia.org/wiki/Adar>, its fairly complex:

"Based on a line in the Mishnah <http://en.wikipedia.org/wiki/Mishnah> 
declaring that Purim must be celebrated in Adar II in a leap year 
(Megillah <http://en.wikipedia.org/wiki/Tractate_Megillah> 1:4), Adar I 
is considered the "extra" month. As a result, someone born in Adar 
during a non leap year would celebrate his birthday in Adar II during a 
leap year. However, someone born during either Adar in a leap year will 
celebrate his birthday during Adar in a non-leap year, except that 
someone born on 30 Adar I will celebrate his birthday on 1 Nisan in a 
non-leap year because Adar in a non-leap year has only 29 days.^[1] 
<http://en.wikipedia.org/wiki/Adar#cite_note-1> "

It appears your previous rules properly handle the 30 Adar I (leap year) 
case, but the new rules do not.  Can we come up with rules that can 
model the 3 cases listed above?

I'm doing some more digging on this and probably need to look at what 
the Chinese do to celebrate birthdates in leap years as well.

Do we have any i8ln experts in the IETF that we can lean on for this stuff?

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University