Why and when storing local time? (Re: Basic rationale of the KEP #2 design)

[Florian v. Samson]

Hello all,

I fully agree with these statements (below) from Jeroen WRT the datetime 
_format_.  

Furthermore Jeroen wrote a single paragraph about the likeliness and 
frequency of changes in the TZ-data, I would like to emphasise and explain 
in more detail, here: see below, inline.

Am Dienstag, 22. März 2011 um 23:26:18 schrieb Jeroen van Meeuwen (Kolab 
Systems):
> Bernhard Reiter wrote:
> > Am Montag, 21. März 2011 15:41:53 schrieb Jeroen van Meeuwen (Kolab
>
> Systems):
> > > The notation would be Zulu (strict writing). 
> >
> > you seem to propose something very similiar to what I have proposed.
> > The only difference I can see is that I would leave out the "Z"
> > which would still be ISO 8601 compliant and make it localtime.
> > Leaving out the "Z" would remove the chance of people interpreting this
> > as an UTC value.
>
> Which is not similar to what I am proposing, as it is our own unique
> format.
>
> > > To indicate the UTC timestamp is to be interpreted (by the parser,
> > > not the human) different, and thus likely to have to be presented
> > > different, the 'tz' attribute can be used. This would apply to 1)
> > > recurring events, 2) events in the future (insert the argument on DST
> > > predictability).
> >
> > See my other post about why I currently believe that saving Localtime +
> > TZ-ID will be better than UTC + TZ-ID. Do you share the argument?
>
> Only in part, as timezone changes (not the same as DST changes) currently
> seem to happen only in Indiana, but even in these cases its counties
> switch between two existing timezones -that's like a traveler, and means
> -in any case- the TZ-ID or datetime would have to be updated for all
> events regardless.
>
> In this day and age, it's considered too intrusive to global trades and
> economics to change the very definition of a timezone. Hence the
> controversy of counties in Indiana changing timezones.

1. Yes, locations switching to some other TZ, hence redefining the 
geographical scope of that TZ and its accompanied TZ-data is nothing we 
really have to care about, IMO.  Only hillbillies seem to be so idiotic to 
do that nowadays (see Jeroen's example), and I do not remember *any* major, 
well populated regions doing so for _many_ decades already.

Aside of changes in the geographical scope of a set of TZ-data (and its TZ), 
there are two more categories of data which may be subject change (AFAICS):

2. the offsets relative to UTC for the regular (i.e. non-DST) and DST 
definition of that TZ; these changes are really rare, I do not remember 
major, well populated regions changing their offsets to UTC for decades.

3. the two DST switching dates (forth and back): even though the whole issue 
with the lacking TZ-information in Kolab-objects was triggered by the 
effects of the politically motivated change (in 2005) of the DST switching 
dates in the North American TZs (becoming effective in 2007), TZ-data 
changes of this category also happen rather seldom.  E.g. the DST switching 
dates for the three European TZs have been static since 1996: the last 
Sunday in March to the last Sunday in October.

So while I do agree that we should model TZ changes of category 3 properly 
(DST switching dates change), and ought to try to also take care of the 
type of TZ changes in the categories 2 and 1, I believe that the whole 
issue has become overrated over the course of this discussion.
TZ changes in the categories 1 and 2 are effectively irrelevant IMO, and 
even for those belonging to category 3 some drawbacks might be acceptable.

The principal issue to solve is still that the current Kolab-format fails to 
capture the TZ in which an event is happening at all!

Cheers
	Florian

P.S.: I do agree with the remainder of Jeroen's email just as much as I did 
with the start of it:

> Additionally, these (sorts of) timezone changes for a geographical
> location are known in tzdata for a good part of the future, so the client
> can correct this if needed.
>
> Furthermore, it breaks compatibility with existing clients. I'm all for
> taking a step back in order to (be able to) move forward, but this is
> quite serious a problem and it seems to have been shoved aside as an
> acceptable downside.
>
> I don't think it is necessary to break compatibility for the use-case we
> find ourselves trying to solve a problem for.
>
> > > Without UTC datetimes, if specified to need to conform to RFC 3339
> > > notation formats, programs cannot use any system library functions to
> > > get the raw data out, because an ambiguous -if not false and/or
> > > invalid- offset may be included in the raw data, negating the value
> > > of the data that is obtained through such functions.
> >
> > My proposal would be fine to use an existing datetime parser which most
> > of the time is more ISO 8601 compliant than strict rfc3339 compliant.
> > (I mean that I can probably find rfc3339 compliant string that break
> > the parser, but the subset I've proposed is more save for the parser,
> > though not rfc3339 compliant.)
>> I think you're mistaken in the perception that:
>
>   20110322T220000
>
> to indicate a local time with is somehow ISO-8601 compliant. Sure it is
> compatible with a selected paragraph, but ISO-8601 specifically refers to
> either UTC *or* local time plus the UTC offset, whenever the time is
> included in the datetime (or in cases the offset is unknown, "-00:00" as
> the offset).
>
> I recon notation formats compatible with ISO-8601 are, not unlike RFC
> 3339, have:
>
>   20110322T220000Z,
>
>   20110322T230000+0100,
>
>   20110322T230000-0000
>
> I recon the specification would explicitly break the standard(s) by
> removing the required timezone indicator or offset, placing it outside
> the datetime.
>
>   http://www.w3.org/TR/xmlschema-2/#dateTime
>
> It can only add to the confusion, especially in cases where "old" (read:
> current) clients remove the tzid attribute from the data and interpret
> the local time to be UTC -and write it out as such.
>
> > > Without UTC datetimes, if specified to not need to conform to any
> > > existing specification -let alone approved in the Internet Society-
> > > we have to invent our own datetime notation format unlikely to find
> > > adoption beyond Kolab XML parsers, likely hindering further adoption
> > > of application compatibility with the Kolab Format, definitely
> > > hindering the Kolab Format from ever becoming a widely accepted,
> > > standard Groupware Format.
> >
> > I do not see that danger, many internetprotocols use other subsets of
> > ISO 8601 and rfc3339 is specifically not for dealing with date that
> > need precise timezone information. And our format is more easy it can
> > very easily precisely defined on the basis of RFC3339 as a variant and
> > is ISO 8601 compliant.
>
> That doesn't parse, I'm sorry.
>
> Kind regards,
>
> Jeroen van Meeuwen