localtime +tz-id how to store

[Bernhard Reiter]

Am Freitag, 1. April 2011 14:23:56 schrieb Georg C. F. Greve:
> On Friday 01 April 2011 12.50:40 Bernhard Reiter wrote:
> > For the datetime stamps in the past and present, we do not need to store
> > localtime + tz-id at all.
>
> That is why these fields do not require TZ-ID. From the KEP:
>
>   * All datetime storage fields MAY carry up to one 'tz' attribute
> describing the time zone in the uniform naming convention designed by Paul
> Eggert, specifying time zones from the Olson database, a.k.a. tz database,
> a.k.a. zoneinfo database.

We are getting closer here,
if you are interpreting 

  * Clients MUST store all datetime fields in their authoritative time zone as 
selected by the user when entering the date/time.

in a way that this only applied to fields where the user explicitely selected 
them, as in future start-data and end-date, this would leave clients
with the options to just write out UTC as they did before on all other tags.
If this, I believe this interpretation should be stronger in the KEP text.

Also we could then just make it mandatory for some texts and just let out 
more unnecessary variants.

>   * 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.
>
> > As appointment start and end times are usually in the future, we use it
> > there always. As for creation-date, we use UTC only.
> > At least this sound sensible to me.
>
> That establishes two different storage formats for datetime, which thus far
> most people considered a recipe for trouble.

No the UTC variant of rfc3339 would be used for creation-date for instance,
which is the same in both proposals.

> It complicates the KEP, requires additional client side logic, and possibly
> even maintaining two parsers instead of one, especially if we do not
> mandate RFC3339 encoding for the time zone sensitive datetime fields.
>
> The sole gain would be a few bytes saved in storage.
>
> So it does not seem overly sensible to me.

That seems to be a missunderstanding of my proposal.
YYYY-MM-DDTHH:MM:SSZ will still have to be parsed in all proposed variants,
the question is if you mandate or allow it for some tags and not for others.

> > In the case of non-UTC data, with the current status of the KEP,
> > all clients will a have to do the extra implementation steps
> > to conform with the KEP. You could change the KEP to say
> > that only tags, X, Y, Z, you need to follow the tz-id preferance
> > or only in some other cases. But as it stands now, those partial clients
> > cannot be sure of the offset to be correct.
>
> No actually, because (a) there is no need to write TZ-ID for those fields,

Okay, with the interpretation above.

> but (b) even if clients did write it with TZ attribute, which they MAY do,
> the other writing requirements are sufficiently strong so the client may
> just ignore the tz attribute and will obtain a sane result.

Okay, the result will be sane, but might be an hour or more off.
In cases I want the real time, I still have to implement the extra loop.

> > rfc3339 + tz-id is something new for many arguments you have presented.
>
> This does not parse. RFC3339 storage is old, and plenty of libraries and
> functions exist for it, so it is clearly not new in the cases where clients
> can just ignore the TZ attribute.

True for those cases it isn't. But there are cases where clients will want to 
take the TZ attribute into account, this is why we are designing it in.
And this is the overal resulting "format", because both parts contain
a necessary and partly overlapping part of the information to come to the 
datetime, we want.

> > My proposal is iso compliant.
>
> Only where the entire environment is restricted 
> to one single local time zone.

No, this is a local time where you have the timezone from the tz-it.
It is the same situation from the implementation side, as when having the 
local time with offset and its timezone where you have to ignore the offset.
Which is what you have to do.

> If you want ISO8601 compliant timezone robust times, you need to include
> time zone information / offsets according to ISO8601, which brings you back
> to RFC3339 if you choose the  simplest approach to do so.

Did you happend to read ISO8601? 
From second hand information my suggestion seems to be iso compliant
and thus parsers will return a localtime object.

> But compliance was not the issue.
>
> The ability of clients, scripts and other tools to use this data without a
> strict requirement for a time zone data lookup was.

Using YYYY-MM-DDTHH:MM:SSZ for those tags where client would want simple 
parsing would be even more easy and ISO and rfc3339 compliant.

Catering for clients that would want to use <start-date>, but not the tz-id,
but the offset is that really a use case that we would like to take into 
account?


-- 
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: 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/20110401/8feabc1b/attachment.sig>