[tz] tabs vs spaces

[Robert Elz]

    Date:        Thu, 2 May 2013 18:44:55 -0700
    From:        Guy Harris <guy at alum.mit.edu>
    Message-ID:  <8EF0A340-6E4C-4D70-ACA4-FEFC25B50D83 at alum.mit.edu>

  | We should also make our current specification of the format a
  | little easier to find, so that people developing consumers other than
  | zic don't write parsers for what they *think* the format is rather
  | than for what we *say* it is.

Actually, I suggest that we should really be discouraging people from
creating alternate parsers for the zone input files than zic - those
two should remain closely tied together.  From time to time we discover
the need to add some new feature to the input language, doing that is
really hard if all kinds of other implementations will suddenly break.

Further, the input file format is rather quirky, and hard to explain 
completely in a way that makes a lot of sense (though it is perfectly
fine for zic).

Rather we should be encouraging people to use the binary output files from
zic for almost all purposes when they need something more than standard
libc functions provide.   And if that means documenting that format, more
than is already done, then let's do it.   It is already difficult to the point
of almost impossibility to make much in the way of changes to that file format,
as it is understood by system's libc functions, that we cannot alter - and
even where libc is normally shared (and so can be updated if needed) nothing
compels users to use the shared version - static program linking works on
every system I'm aware of.  If the binary format changes in some incompatible
way, all old static linked programs would stop working, which is an
unaceptable result (which is why we never do that, at most we have, very
rarely, added to that format in a way that doesn't break existing parers).

This does mean that people may need to use a new zic to handle new tzdata
distributions, but that should be easy (if it isn't, we should be fixing
whatever the problem is to make it easy.)

Anyone who does insist on parsing the input files themselves should be made
to understand the risks involved - we have in the past, and I am sure will
again in the future, make changes to that format, with zero advance notice
(beyond normal code review here).

Of course, that we can change it does not mean that we must, or even should,
and there's been nothing in this recent discussion that even suggests to me
any need to make any kind of change.

kre