Subject: [VCARDDAV] Non-gregorian dates

From: Cyrus Daboo <[email-masked]>
Date: Sun, 17 Jan 2010 15:25:30 -0800

Hi folks,
I have heard from a number of people who would like to specify 
non-Gregorian dates (and partial dates) in vCard properties. Whilst I do 
not proposed we add explicit support for that in vCard 4, I would suggest 
we follow the iCalendar approach and define a CALSCALE parameter that can 
be used on any property that includes a date value (either a DATE/DATETIME 
value type or TEXT). That parameter would be defined with a single value, 
"GREGORIAN", which would be the default if is in not present. We would add 
an IANA registry for new values. We would need to add a requirement for 
clients about how to deal with CALSCALE values they do not recognize - 
basically ignore the property or treat it as text.

NB this is important for things like birthdays which, if specified in a 
non-Gregorian calendar, do not always map to the same Gregorian date 
year-to-year.

-- 
Cyrus Daboo

---

From: Mike Douglass <[email-masked]>
Date: Sun, 17 Jan 2010 15:35:18 -0500

Would it be appropriate to allow for multiply occurring properties in
this case, for example allowing a birthday to appear in GREGORIAN and
some other calscale - or is that essentially already covered?

It seems likely (an open invitation for correction) that an application
generating vcard that understands a non gregorian scale would also be
able to produce gregorian equivalents.

Given the note it's apparent that producers and consumers would need to
refresh their information periodically - but then we have CardDAV for that.

Cyrus Daboo wrote:
> non-Gregorian dates (and partial dates) in vCard properties. Whilst I
> do not proposed we add explicit support for that in vCard 4, I would
> suggest we follow the iCalendar approach and define a CALSCALE
> parameter that can be used on any property that includes a date value
> (either a DATE/DATETIME value type or TEXT). That parameter would be
> defined with a single value, "GREGORIAN", which would be the default
> if is in not present. We would add an IANA registry for new values. We
> would need to add a requirement for clients about how to deal with
> CALSCALE values they do not recognize - basically ignore the property
> or treat it as text.
>
> NB this is important for things like birthdays which, if specified in
> a non-Gregorian calendar, do not always map to the same Gregorian date
> year-to-year.
>

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

---

From: "Andy Mabbett" <[email-masked]>
Date: Sun, 17 Jan 2010 20:49:01 -0000

The "Extended Date/Time Formats" efforts:

   http://www.loc.gov/standards/datetime/

may be relevant here.

On Sun, January 17, 2010 23:25, Cyrus Daboo wrote:

> [...]

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk
** via webmail **

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 17 Jan 2010 20:24:00 -0500

Hi Andy,

>    http://www.loc.gov/standards/datetime/

I had a quick skim over that and it only seems to deal with Gregorian, 
unless I missed something.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 17 Jan 2010 20:31:58 -0500

Hi Mike,

> refresh their information periodically - but then we have CardDAV for

An exact date can easily be mapped between different calendar systems using 
well known algorithms. What can't be done easily is partial dates - in some 
ways this is similar to recurrence patterns in iCalendar which are also 
very calscale specific. In this case consider my "partial" birthday:

BDAY:??0921

That won't necessarily map to the same date in other calendar systems for 
different years. e.g. (using <http://www.hebcal.com/converter/>). For 2010 
the Hebrew date is "13th of Tishrei, 5771", for 2011 it is "22nd of Elul, 
5771". Now I honestly don't know how one would represent something like a 
birthday in the Hebrew calendar or others (something I would like to 
research if I did not have plenty of other things to do) but I know users 
do want to be able to do that.

-- 
Cyrus Daboo

---

From: Ned Freed <[email-masked]>
Date: Sun, 17 Jan 2010 19:25:21 -0800 (PST)

> may be relevant here.

I'd be delighted to see an effort too systematize and standardize formats for
the handling  of non-Gregorian dates, but this doesn't appear to be it. Rather,
this effort seems primarily focused on adding additional syntaxes for Gregorian
dates. That's certainly of interest in the XML world, where compatibility with
existing database records and whatnot is a real issue. But doesn't seem
relevant here.

The work on partial and approximate dates may be of interest, but it's not
getting at the non-Gregorian date issue at all.

In any case, I agree with Cyrus that adopting and/or adapting the iCalendar
approach makes all kinds of sense.

				Ned

---

From: Simon Perreault <[email-masked]>
Date: Mon, 18 Jan 2010 11:29:36 -0500

Cyrus Daboo wrote, on 2010-01-17 18:25:
> not proposed we add explicit support for that in vCard 4, I would
> suggest we follow the iCalendar approach and define a CALSCALE parameter
> that can be used on any property that includes a date value (either a
> DATE/DATETIME value type or TEXT). That parameter would be defined with

Why TEXT? It would need many more changes to the grammar than necessary.

> a single value, "GREGORIAN", which would be the default if is in not
> present. We would add an IANA registry for new values. We would need to
> add a requirement for clients about how to deal with CALSCALE values
> they do not recognize - basically ignore the property or treat it as text.

Makes senses. Will be added in next release.

Simon

P.S. Is it allowed to perform trades such as "I will add your feature if you
review my draft?" ;)
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: "Andy Mabbett" <[email-masked]>
Date: Mon, 18 Jan 2010 18:27:49 -0000

> unless I missed something.

You did ;-)

See item 13, "Non-Gregorian dates" on:

   http://www.loc.gov/standards/datetime/proposals.html

Regards,

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 18 Jan 2010 20:08:09 -0500

Hi Andy,

>    http://www.loc.gov/standards/datetime/proposals.html

Ah, OK. Well it does not have a lot to say about that - but I guess we're 
all in that same boat right now.

-- 
Cyrus Daboo

---

From: "Andy Mabbett" <[email-masked]>
Date: Tue, 19 Jan 2010 13:35:19 -0000

> all in that same boat right now.

It's probably worth checking the associated mailing list for recent
developments; and notifying them of the recent proposal here.