[tz] [PATCH 2/3] Replace some zones with links when that doesn't lose non-LMT info.

[Guy Harris]

On Sep 4, 2013, at 2:32 AM, Stephen Colebourne <scolebourne at joda.org> wrote:

> Thirdly, I note that the leading supporters of Paul's approach are
> from an academic background (Paul, Guy, yourself).

Actually, no, I'm not "from an academic background", except to the extent that I have an academic degree; everywhere I've worked since 1979 was a business of some sort, not in academia.  ("alum" is short for "alumni"/"alumnae", if you're guessing from my e-mail address that I work in academia; it's a mail-forwarding service.)

> With respect, I wonder if that academic background insulates from the needs of
> enterprise software, primarily stability.

I've worked as a software developer at various companies, such as Sun Microsystems, Network Appliance, and Apple; only one of them was a major producer of "enterprise" equipment when I worked there (Sun was a technical workstation company, not "the dot in dot com", then, and Apple hasn't been particularly enterprise-oriented in ages).

As for whether I'm a "supporter of Paul's approach", I think that's an overstatement.  I'm somebody who's certainly sympathetic to concerns about having to offer end-users choices between tzids that won't make any real difference to them in practice - i.e., I'm not 100% an *opponent* of Paul's approrach - but I think the *ideal* way to handle that is not to offer end-users choices between tzids, which is why I've cited OS X's "Time Zone" subpane of "Date & Time" in System Preferences as the right way to handle that, rather than the cheesy "I know!  I'll just turn all the underscores in tzids into spaces and make an option menu out of them!" stuff done by some other OSes.  There are now data files freely available that can support that.

For developers that are hard-coding tzids into code or files, they'd have to know what they're doing and pick the appropriate tzids.  For those letting the users specify a tzid, something OS X-style would be best, so they don't need to know about tzids.

> Finally, I'm NOT asking for all historical data to be frozen. I'm
> asking for no historical data to be changed UNLESS the replacement is
> a clear enhancement. This is a common sense and perfectly reasonable
> request of the database. Its also how all well-resected APIs and data
> sets (like CLDR) operate. Such an approach does explicitly rule out
> zone ID merging that loses the start date of offsets or abbreviations,
> even if those are guesswork/invented (because the replacement is not
> an enhancement, its worse).

I personally think it reasonable that if two entries differ in the start date for standardized times, *and* the start dates have a reliable source for them, they not be coalesced.

If the start dates are just guesses, that sounds like a change from one set of data that won't necessarily give you the same answer to another set of data that won't necessarily give you the same answer, so I don't think it's clear that merging them is a bad idea - stability might be an argument against merging them, but the only way in which the old data could be considered "better" is that it doesn't represent a change, not that it necessarily better reflects reality.

I.e., in the case you mention, the replacement is "worse" only in that it's different, not in that it's further from reality.

And I think anybody using the tzdb to handle pre-1970 dates, or claiming that their APIs can be used to handle pre-1970 dates, should either state it as "you can use it, but we make no claim that the results will be correct, so don't rely on it for anything where a difference of an hour or two will actually matter" or should back up their confidence with historical research (and send the results of that research to Paul so the comments can be updated).