RE: issue regarding daysInYear in CalendarRepeatRule API

Harshad wrote:
> I think in CalendarRepeatRule in daysInYear we have max limit of 365 days, but
> in leap years max number of days is 366.
> So we need to change upper limit to 366 and mark that leap year check would
> be developer's responsibility.
> 
> Kindly let me know if my doubt is wrong or right.

You're technically right that there's an underdefined edge case, however:

1. We're not actively working on Calendar. You can look at our roadmap [1]. -- It isn't officially shelved, it should be, I sent an email to rectify that [2].

Please note this important section of the Calendar Status of This Document which explains [3]:
> The approach proposed for this API is very similar to the one taken in the Contacts API.

The version of Calendar that we hope to eventually advance to REC should satisfy that, the version you're looking at hasn't been touched in a year because we were working on Contacts, and only recently managed to get Contacts working in a direction we like (which doesn't match the old direction for Contacts upon which the Calendar document that you're reviewing is based)

> This document was published by the Device APIs and Policy Working Group as a First Public Working Draft.

This is a FPWD, not a LC/PR/REC

> Publication as a Working Draft does not imply endorsement by the W3C Membership.
> This is a draft document and may be updated, replaced or obsoleted by other documents at any time.
> It is inappropriate to cite this document as other than work in progress.

Unfortunately this document isn't really properly in progress, many documents in W3 space are stale, and there aren't particularly good provisions to fix this. The DAP working group is trying to Shelve [4] documents in order to aid readers such as yourself in understanding that documents are no longer being maintained and haven't reached REC.

2. The text says:

> daysInYear of type array of short
>     NOTE: This property only applies to yearly occurrences. If CalendarRepeatRule.frequency is not set to 'yearly' this property must be ignored.

An event that occurs on Feb 29 does not occur yearly, it occurs once every 4 years, and thus it technically is correct to say that repetitions of the form 1..365 are acceptable, and a 366 isn't, but the 366th day that can't be represented isn't Dec 31 of a leap year, but instead Feb 29th of the leap year. If you want to represent Feb 29th, you'll have to do something else. Offhand, it looks like there are no provisions in the spec for leap years.

We'll want to make sure that the replacement API considers this. However, my guess is that we'll instead try to rely on third parties to innovate in this area instead of trying to define this and getting it wrong.

In short: please feel free to collect and send us feedback, however please do *NOT* implement this API. It isn't a REC, it won't be a REC, and thus you shouldn't implement it, and you certainly shouldn't expose it to the world.

[1] http://www.w3.org/2009/dap/#roadmap 
[2] http://lists.w3.org/Archives/Public/public-device-apis/2012Sep/0097.html
[3] http://dev.w3.org/2009/dap/calendar/
[4] http://lists.w3.org/Archives/Public/public-device-apis/2011Nov/0026.html


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Wednesday, 19 September 2012 17:27:26 UTC