Re: [VCARDDAV] Format of various date fields

["Darryl Champagne" <dgc at funambol.com>]

> -----Original Message-----
> From: vcarddav-bounces at ietf.org [mailto:vcarddav-bounces at ietf.org] On
> Behalf Of Simon Perreault
> Sent: Thursday, May 08, 2008 8:48 AM

> 
> On Wednesday 07 May 2008 22:04:19 Darryl Champagne wrote:
> > Again - I do not care which format is selected, but I am trying to point
> > out that exactly specified formats would be much easier to deal with in
> the
> > mobile world than nearly freeform text, and also would work better for
> > comparison purposes (e.g. if during a Sync I am comparing 1800+-50 years
> > from one side, and 1820 from the other, I can reasonable choose the 1820
> > value, but I am unlikely to know how to deal with "circa" or "~" or
> "just
> > before", but any user interface that allows circa can easily pick a
> > reasonable range).
> 
> Here's my 2¢:
> 
> - I think that the DATE, TIME, and DATE-TIME value types are *very well
> defined* and that converting to/from them will not be ambiguous at all. Do
> you disagree?

They are relatively well defined, but not as simple as they could be -
Primarily in the optional "-" and ":" characters (and that each one is
individually optional per the abnf, rather than either use them for all or
not as per ISO).  Do we really need both basic and extended format, and
should a mix (e.g. 2008-0612) be allowed, as per the abnf?

I have to ask what value is gained by this.  Clearly it is not difficult to
grab the year, and then check for a "-" and skip it if present, and so on,
but it prevents simple clients from just doing a blind string compare, which
does happen during synchronization (checking for duplicates, and checking
for rev changes).

My other concern relates to issue ID 236 - the request to allow for month
and day without year.  If this is allowed, which would presumably require
the leading dashes, why not just require dashes uniformly?

> 
> - Resetting a DATE/TIME/DATE-TIME-valued property to freeform text implies
> that any comparison is futile. This is opaque text and you're not supposed
> to
> interpret it. Just store it as opaque text. If you can't, drop it, and
> accept
> that you're not implementing vCard fully (for potentially valid reasons
> like
> lack of storage, etc.)
> 

My concern is that for certain clients (I would expect a pretty decent sized
set), freeform text just means there is no meaningful data supplied, yet the
field and its useless data is present and being transferred.

> It would be much harder on the implementation if we would specify a date
> format for expressing uncertainty and precision than just allowing the
> property to be reset to freeform text (which is not supposed to be
> interpreted).

Why? I didn't state that uncertainty support is required. If one does not
choose to support uncertainty, then consider the plus or minus part as just
text - how would that be any different (other than having some additional
information)?  You would have a date that could be recognized, plus some
extra stuff that would be discarded (or stored).  Isn't that better than
having nothing?  

Is there some other need for freeform text?  

If vCard isn't supposed to support genealogy (as per issue 156), then why
support circa and all that?  If it's not required, then let's avoid having
the text option.  If reduced precision is desired (issue 236 & 156), then
just define it (and using a date plus a duration of uncertainty, or a start
and end date can also work).  For that matter, if genealogy support might be
desirable, since it is part of the information about an individual, which
can go into a "data format for representing and exchanging a variety of
information about an individual", then having the items 156 may as well be
defined (or reserved, like a GEN- prefix).

> _______________________________________________
> VCARDDAV mailing list
> VCARDDAV at ietf.org
> https://www.ietf.org/mailman/listinfo/vcarddav

_______________________________________________
VCARDDAV mailing list
VCARDDAV at ietf.org
https://www.ietf.org/mailman/listinfo/vcarddav