KEP #2: datetime RFC3339 and ISO 8601 and requirement of tz

Bernhard Reiter bernhard at intevation.de
Wed Mar 2 11:29:11 CET 2011


Am Dienstag, 1. März 2011 18:44:34 schrieb Till Adam:
> > Not all variants of RFC3339 make sense to have in the storage.
> >
> > I'd rather force writing of one variant of RFC3339 (which I gave)
> > and add a "to make implementation easier clients MAY use a system
> > function call for reading the datetime field and accept all sensible
> > values."
>
> I'm still not conviced the extra constraint pays off, but I'm not strongly
> opposed to adding a suggestion about the prefered serialization.

The current KEP2 id=10864 allows for the following values for instance
1990-12-32T23:59:60.123456789+08:00
and then you can add a timezone which 
needs to take precedence over the +08:00 meaning I am not sure
that all available library functions can deal with correctly.

For example Package: libqtcore4, Version: 4:4.6.3-4 Debian GNU Squeeze
fails to interpret rfc3339 correctly for me:
    // rfc3999 says those two examples shall be equivalent
    QDateTime time0 = QDateTime::fromString("1996-12-19T16:39:57-08:00", 
Qt::ISODate);
    QDateTime time1 = QDateTime::fromString("1996-12-20T00:39:57Z", 
Qt::ISODate);
    QCOMPARE(time0.toUTC(), time1);
FAIL!  : TestRFC3339::rfc3339() Compared values are not the same
   Actual (time0.toUTC()): 1996/12/18 23:00:00.000[UTC]
   Expected (time1): 1996/12/20 00:39:57.000[UTC]
(I attach the full test application. Haven't tested Qt 4.7.2 yet.)

So using that Qt library and function would get your implementation
to be in violation of the KEP2 id=10864.

I expect many library functions to have issues with the finer details
of ISO 8601 and possibly RFC3339 and our timezone use case.

Note that even RFC3339 says that UTC is best for interoperability:
   4.1. Coordinated Universal Time (UTC)
   Because the daylight saving rules for local time zones are so
   convoluted and can change based on local law at unpredictable times,
   true interoperability is best achieved by using Coordinated Universal
   Time (UTC).  This specification does not cater to local time zone
   rules.

Of course this does not help us to model what the user wants, this is why I 
think the current proposal is good to add the "tz" attribute for the field
where we must have it. Especially future datetimes and start and end times of
recurrences. We must have a tz id for this.

> > So forcing a change as a requirement for all datetime objects in all
> > Kolab objects has the advantage of being more consistent, but also
> > drawbacks. For last-change values there is no extra gain in having the
> > local time zone. It is harder to read, as it needs two translations when
> > the local time given is not mine: Local time new sealand -> UTC -> Local
> > Time Germany. And it forces data updates at least at write time.
>
> As soon as any field requires it, we need to implement that conversion
> anyhow, and our platforms already provide it, nearly everywhere. 

I agree that the conversion function must be there, so it could be used
everywhere. Human readability goes down a bit, because of the two
conversions if this is done.

> The user doesn't see the timezones where it makes sense, 
> and the machines do not care, they simply consistently
> call the same date management method everywhere. 
> Less code, cleaner code, easier to write, easier to maintain,
> no special cases.  

> I don't think there is a need to change existing objects, 
> unless they are written out anyhow. If they are written out anyhow, because
> of some semantic change, writing out a few more fields is of no concern.

Given my reading mistake, "Contacts" objects would not change, which I 
interpret would not lead to massive update writes and old clients could still 
use the old ones. This is good.

> All implementations I'm aware of replace the full mime attachment anyhow
> for every write, so there's no performance difference, or implementational
> overhead.

I agree that the added overhead in size is not that important.

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testrfc3339.cpp
Type: text/x-c++src
Size: 614 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/format/attachments/20110302/9e7b7a74/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110302/9e7b7a74/attachment.sig>


More information about the format mailing list