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

Bernhard Reiter bernhard at
Wed Mar 2 11:47:56 CET 2011

Am Mittwoch, 2. März 2011 10:40:14 schrieb Jeroen van Meeuwen (Kolab Systems):
> Bernhard Reiter wrote:
> > 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 think that is what "strict writing, loose parsing" is supposed to cover,
> isn't it?

I agree that should be the basic principle.
However KEP2 id=10864 falls short in mandating it in a good way:
a) It adds a MUST for rfc3339 parsing and a SHOULD for ISO 8601 parsing
   Where I would say make it a "MAY" to use functions and thus relaxed 
   checking on RFC3339. Maybe a SHOULD for rfc3339 would be okay. 
   However I believe backwards compatibility is not an issue, so there
   is no need for loose parsing. And forcing to add a precise rfc3339 parser
   can be a problematic requirement. (See defect in qt 4.6.3)
b) A stricter subset of RFC3339 is only mandated by the KEP in the UTC case.
   Not in the other cases. (At least this is my reading.)

When rereading this: "All fields that store future dates at the time of 
writing an entry, e.g. the 'start-date' and 'end-date' fields, MUST define 
the 'tz' attribute. Where the event should be calculated strictly against 
UTC, emulating previous behaviour, the value of the 'tz' field must be set 
to 'UTC' (all caps) explicitly."

The previousbehaviour was to calculate the recurrent appointments from the 
shift  on ones own timezone (Kontact e35 and Outlook 2003 on invitations do 
this.) Note strictly according to UTC (which is that Outlook 2007 did in my 
test). So the current draft cannot emulate the previous behaviour (which is 

Managing Director - Owner:       (Free Software Company)
Deputy Coordinator Germany: Board member:
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: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the format mailing list