New home for time zone stuff by 2012?
Eric Muller
emuller at adobe.com
Mon Aug 31 17:09:29 UTC 2009
Of the pieces of the puzzle that Arthur listed, some are not very
problematic to transfer:
- data distribution
- code distribution
- mailing list maintenance
- mailing list hosting
I think everybody will agree that tz does not have special demands for
those and that there are multiple adequate solutions. (In the interest
of full disclosure, I am an officer of the Unicode Consortium, and I
think that unicode.org would be a very nice solution.)
The interesting part is of course the rest. Before arguing one way or
another, I think it would be a profitable exercise to try to
characterize how the tz project works. Here is my take; it is based on
having followed this list for the past 5 years, but I am not a direct
user of tz. I probably have some of the facts wrong, it's definitely not
intentional.
Let's look at the data maintenance:
There are folks in the world who have a vested interest in having tz
up-to-date. May be they incorporate it in their product, may be they
live in countries with unpredictable DST changes. Together, they track
the changes, and over time, they have figured out the best way: find
some kind of verifiable source (if possible official) that describes the
changes, and provide that to the list; it's even better if there is a
patch that goes with it. Arthur collects those, and when he deems the
collection large enough or there is something imminent, he proposes a
cumulated patch. A little bit of checking, and bingo, we have a new
version of tz. I seems to remember that at some point, Paul Eggert also
played that role as much as Arthur, but I find less traces in the recent
past.
I think the main reason this process works (and it works really well, as
far as I can tell), is that everybody trusts Arthur and likes what he
does: that he double checks the changes to ensure the integrity of the
data (or at least publish the proposed changes), that he makes timely
releases and that he does not take advantage of anybody. The last point
is important: I have the sense that the community really believes that
it owns tz, and that tz is nothing more than the community. There is no
formal organization that owns it.
I have not followed the code maintenance as much, but I have the
impression it follows about the same process. The needed changes are
less obvious and take a bit more discussion, and the work is a bit more
distributed.
So what is your perception of how the tz project works, and what aspects
do you value (beyond the resulting database)?
Eric.
More information about the tz
mailing list