Re: [VCARDDAV] Format of various date fields

[Simon Perreault <simon.perreault at viagenie.ca>]

On Thursday 08 May 2008 21:28:45 Darryl Champagne wrote:
> > - 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?

Oh, sure, purely syntactic issues are easy to fix. Consider it done.

   date = date-fullyear ["-" date-month ["-" date-mday]]

   time = time-hour [":" time-minute [":" time-second [time-secfrac]]]
           [time-zone]

> > 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?

Well, "circa 1800" is really not the same as "1800". In many cases dropping 
the uncertaincy indicator could be worse than dropping the whole thing. I'm 
not sure making support for uncertainty optional would be a good idea.

> 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).

Now let's not get into a false dichotomy.

I'd like to hear other people voice their opinion on this issue. What should 
we do about uncertainty in date/time fields?

- Have it be resettable to a text value.
- Extend the format with "± ..."
- Do both.
- Do nothing.
- Do something else: ...
_______________________________________________
VCARDDAV mailing list
VCARDDAV at ietf.org
https://www.ietf.org/mailman/listinfo/vcarddav