Subject: [Jcardcal] Timestamp and date-and-or-time

From: Philipp Kewisch <[email-masked]>
Date: Wed, 27 Mar 2013 19:52:08 +0100

A futher open issue is Timestamp and date-and-or-time.

As we previously found out, not adding these as separate types breaks roundtripping:

X-UNKNOWN;VALUE=timestamp:20120101T010203Z 
[ "x-unknown", {}, "date-time", "2012-01-01T01:02:03Z" ] 
X-UNKNOWN;VALUE=date-time:20120101T010203Z

X-UNKNOWN;VALUE=date-and-or-time:20120101
 ["x-unknown", {}, "date", "2012-01-01"] 
X-UNKNOWN;VALUE=date:20120101 

On the one hand we would be breaking roundtrip, but on the other hand we are not really producing wrong data. In the above cases, the timestamp is also a date-time and the date-and-or-time is also a date. If the client wants to set a time on the property, then the value parameter can be changed easily.

The burden we would be putting on parser/converter libraries is type detection. If a date-and-or-time is a date it needs to be converted as such. On the way back, the library (that knows default types for known properties) would have to make sure to either specify or drop value type as appropriate. 

There could be further implications with truncated and reduced representations I am unaware of.

On the bright side, this might be a first step in condensing the number of types in vcard 5.0. Also, since jCard is more type safe, there should be no further issues on the jCard side.

What do you think?

Philipp

---

From: Simon Perreault <[email-masked]>
Date: Wed, 27 Mar 2013 20:02:12 +0100

Le 2013-03-27 19:52, Philipp Kewisch a écrit :
> On the one hand we would be breaking roundtrip, but on the other hand
> we are not really producing wrong data.

One problem with breaking roundtripping is that it puts a burden on sync 
engines. There *has* been a change, and they *have* to propagate it. 
That may mean increasing the REV number. And it may trigger another 
rountrip to jCard. I could even envision a rountripping loop. Not fun.

> What do you think?

I don't know. Maybe I'm parano.

What's the problem with just defining all vCard date/time types in jCard 
again?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Philipp Kewisch <[email-masked]>
Date: Wed, 27 Mar 2013 20:13:22 +0100

I don't see a big problem in keeping those types in jcard, I was just trying to get rid of redundant information. Another petty reason is that typing date-and-or-time is so long ;-)

Before we shoot ourselves in the back with this one maybe it would be smart to just introduce the types.

Philipp

On Mar 27, 2013, at 20:02, Simon Perreault <[email-masked]> wrote:

> One problem with breaking roundtripping is that it puts a burden on sync engines. There *has* been a change, and they *have* to propagate it. That may mean increasing the REV number. And it may trigger another rountrip to jCard. I could even envision a rountripping loop. Not fun.
> 
>> What do you think?
> 
> What's the problem with just defining all vCard date/time types in jCard again?
> 
> Simon
> -- 
> _______________________________________________
> jcardcal mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jcardcal