Subject: Re: [VCARDDAV] Format of various date fields

From: Mark Paterson <[email-masked]>
Date: Tue, 10 Jun 2008 17:59:42 -0400

Not sure we closed this thread. See below.

Proposal was to define that valid date time values be the same as in 
iCalendar RFC2445.bis.

Mark

Mark Paterson wrote:
>
>
> Simon Perreault wrote:
>> 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]
>>   
> That unfortunately does not fix the greater issue Darryl is trying to 
> solve.
>
> And it doesn't answer the question, "Do we really need both basic and 
> extended format?", iCal doesn't and most of the IOP issues between 
> iCal implementations are not problems regarding the date format. This 
> is because iCal is far more precise about what is a valid date-time 
> value. Having both iCal and vCard agree with each other seems like 
> something that would  help reduce interoperability issues
>>   
>>>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/vcarddav
>>   
>
> -- 
>
>
> Oracle Email Signature Logo
> Mark Paterson | Product Manager, UC & Mobile Services | 514.905.8649
> Oracle Server Technologies - Collaboration
> 600 Blvd. de Maissoneuve West, Suite 1900, Montreal, Quebec, H3A 3J2

-- 

Oracle Email Signature Logo
Mark Paterson | Product Manager, UC & Mobile Services | 514.905.8649
Oracle Server Technologies - Collaboration
600 Blvd. de Maissoneuve West, Suite 1900, Montreal, Quebec, H3A 3J2
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Simon Perreault <[email-masked]>
Date: Thu, 12 Jun 2008 12:55:13 -0400

> Proposal was to define that valid date time values be the same as in

Some things need to be different:

- We need to be able to account for missing fields (issue 236).  The basic 
format doesn't allow that.

- iCalendar has a timezone definition mechanism which we don't want to include 
in vCard. Instead, the proposal (issue 187) is to follow RFC 4833.

-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav