KEP #2: datetime RFC3339 and ISO 8601 and requirement of tz
bernhard at intevation.de
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: 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...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the format