Proposal was to define that valid date time values be the same as in iCalendar RFC2445.bis.
Mark
Mark Paterson wrote:
Simon Perreault wrote:That unfortunately does not fix the greater issue Darryl is trying to solve.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]
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 thclosed 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:That unfortunately does not fix the greater issue Darryl is trying to solve.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]
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 formate format with "± ..." - Do both. - Do nothing. - Do something else: ... _______________________________________________ VCARDDAV mailing list VCARDDAV at ietf.org https://www.ietf.org/mailman/listinfo/vcarddav
--
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
--
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
