Version control? Changelog? Good list of regions/paths aligning with US DST changes?
I know this is a tall order. Not looking for anyone to fill it either. I can do my own research, so pointers are always recommended. If I've overlooked this info on the TZ page, my apologies, just [re]point me to it. - Is there a version control repository for zoneinfo? - Or a changelog of any corrections/additions? More to the point, I'm looking for a good list of any regions/zoneinfo paths that are aligning their changes with the US DST changes. I noted several were announced in 2006. I hope I'm not the only schmuck out there trying to track this. I'm hoping someone else has such a list, a blog, etc... If not, I might blog myself, even if it's just a tiny subset and focuses only on the US changes (and ripples from it) going into effect for 2007. Even longer story short, I'm tracking a number of embedded solutions and their tzdata (or lackthereof) updates. Just looking for a good authority on any and all tzdata changes since the 2005 legislation for the 2007 change. E.g., Red Hat has several errata for its tzdata package: - RHEA-2005:655-7: USA, Australia, Haiti, Nicaragua ... - RHEA-2006:0213-7: join US DST change, Canada, Indiana/USA ... - RHEA-2006:0277-7: Sri Lanka - RHEA-2006:0745-3: Western Australia DST But embedded developers like Montavista** only released 1 change (possibly not addressing Canada, etc...): - Fix 15446 (2005Nov): NA timezone file to include the latest DST Ultimately I'm trying to come up with a test plan to verify updates for all major financial/trading regions where our equipment runs. I think I can safely ignore the Indiana changes, etc..., and stick with major regions. -- Bryan J. Smith Professional, Technical Annoyance b.j.smith@ieee.org http://thebs413.blogspot.com -------------------------------------------------- Fission Power: An Inconvenient Solution
"Bryan J. Smith" <b.j.smith@ieee.org> writes:
- Is there a version control repository for zoneinfo?
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.
- Or a changelog of any corrections/additions?
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.
I think I can safely ignore the Indiana changes, etc..., and stick with major regions.
Well, Indiana is a major region for us! (I guess Bill Cook doesn't use your financial applications, huh? :-)
Paul Eggert <eggert@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 setup.py script (you can change from an in-line to side-by-side view using the Javascript form on the upper-right -- try it out): http://trac.edgewall.org/changeset/4295/trunk/setup.py?old=4213&old_path=tru... 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 server.
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@ieee.org http://thebs413.blogspot.com -------------------------------------------------- Fission Power: An Inconvenient Solution
participants (2)
-
Bryan J. Smith -
Paul Eggert