Version control? Changelog? Good list of regions/paths aligning with US DST changes?

Bryan J. Smith b.j.smith at
Thu Jan 4 22:59:57 UTC 2007

Paul Eggert <eggert at CS.UCLA.EDU> wrote:
> Nothing that's public.  Arthur has his own repository, in SCCS
> form.  I keep a copy, in RCS form, of all the public versions I
> could get my hands on, along with all my private changes.
> I've been meaning to publish a repository (hopefully a combined
> version) on the web, but haven't had time.

I was just going to throw up some static HTML pages built from Trac.
They are very, very nice for graphically looking at changes.  If you
haven't seen how Trac can compare revisions, you've really been
missing out.

Here's an example from Trac's own self-hosted project, just the script (you can change from an in-line to side-by-side view
using the Javascript form on the upper-right -- try it out):

You can change from in-line to side-by-side too.

Just copy the support css files and save the page and, bam, you have
a static HTML version.  I do that all-the-time for various
internal/external projects -- since I don't have a public SVN+Trac

> No, sorry.  Also on the list of things to do.  The closest thing
> to a changelog would be the first parts of email of mine to tz@
> containing proposed changes.

Just something like this would go a long way.

SVN+SSH is easy to setup, and a read-only Trac service (under Apache)
beyond that is easy too.  Trac only becomes a headache if you start
adding in ACLs, which is not necessary for read-only access to the
SVN repo (which is all I use it for).

> Well, Indiana is a major region for us!  (I guess Bill Cook
> doesn't use your financial applications, huh?  :-)

My point was that every, major financial trading house I've seen
operates on one of the major timezones.  I.e., the in-house systems
would use America/New_York (EST5EDT) or America/Chicago (CST6CDT),
depending on the location in Indiana.

We don't sell "software," we sell trader systems/entire solutions. 

We're using Montavista, so unless we want to take on a burden (which
we may), we try not to deviate.  I've been arguing that we need to be
maintaining our own, internal toolchain and builds (we certainly
fight more than we gain with going with another solution), but that's
largely been argued by many and ignored by others.

Just kinda sad that Montavista hasn't updated their tzdata since
2005Nov11 (Fix 15446) for release 3.1.  Not good IMHO.

Bryan J. Smith   Professional, Technical Annoyance
b.j.smith at
     Fission Power:  An Inconvenient Solution

More information about the tz mailing list