Date: Mon, 10 Oct 2011 10:18:31 +0200 From: Alan Barrett <apb@cequrux.com> Message-ID: <20111010081831.GA620@apb-laptoy.apb.alt.za> | I also see a change for America/Sitka in the "northamerica" source file: Yes, that was an (obvious - once it was pointed out) typo reported by Zefram on Oct 1 (and was mentioned in the preview of the changes) -- being way back in the past, it doesn't affect the generated data files, so I didn't bother to mention it again. kre

On 2011-10-10 17:42, David Zülke wrote:

On 10.10.2011, at 06:42, Robert Elz wrote:

...

The file ... ftp://munnari.oz.au/pub/tzdata2011l.tar.gz ...is now available; this reflects changes circulated last week on the time zone mailing list.

There are just 2 changes that cause different generated tzdata files from zic, to Asia/Hebron and Pacific/Fiji - the possible change for Bahia, Brazil is included, but commented out. Compared with the diff I sent out last week, this version also includes attributions for the sources for the changes (in much the same format as ado used, but the html tags have not been checked, verified, or used in any way at all, so if there are errors there, please let me know.)

You did not increment the version numbers in the files you changed, so southamerica is still at 8.50, northamerica still at 8.49, australasia still at 8.27 and asia still at 8.68.

Those version numbers are automatically generated by the SCCS version control system that Arthur uses, not entered manually. Since neither Robert nor anyone else other than Arthur (with the possible exception of Paul?) have access to the master repository, the automatic generation is not possible. It still begs the question of what to do about them for these releases while everything's still up in the air pending the court case. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-

Sorry for mail format, replying on phone during a break in class. In the past ado has incremented the sccs release number. There was a reset of all numbers to 8.1 at one point for instance. Based on the sccs tools that would be easier for him to important changes made in his absence. I can redo my patch if you would like. On Oct 10, 2011 8:17 PM, "Robert Elz" <kre@munnari.oz.au> wrote:

Date: Mon, 10 Oct 2011 18:42:16 +0200 From: David Zülke <david.zuelke@bitextender.com> Message-ID: <D6D084ED-BABA-4BF7-BA4F-69CA4C3FC41A@bitextender.com>

| You did not increment the version numbers in the files you changed,

Ian Abbott indicated the source of those, but not withstanding that, I could have updated them (manually) I just decided not to, for now. However, if having those version numbers updated is useful to people (and I know they have been used in the past to confirm that you are at the latest version in case of apparent discrepancies) I can do it - if that's what people prefer.

I can see three ways (and there could of course be more) that that could be done - aside from just doing nothing ... First, would be to pretend to be sccs, and produce numbers indistinguishable from what it would produce. Second, would be to modify the numbers in a way sccs would not, but still allow them to move "forward" - the easy way to do that would be to append a sub-version number (making say 8.50.1 for northamerica) and just continue from there, leaving 8.51 for ado's next version, if that ever happens. [Aside: yes, I know a sccs branch could produce a number like that, but the tz files have no branches, and in any case, sccs would add 2 sub-version numbers, I believe, never just one.] Or, third, I could insert my owv version numbers to run in parallel - I have the data in RCS files (just for convenience, some of you probably already detected that from looking at the precise details of the diff I sent out) and RCS has its own version numbering scheme, I could just add those version numbers (they they could be removed again sometime later).

Which do you all prefer?

Řyvind Holm <sunny@sunbase.org> said: | But I notice there's lots of unrelated files and directories in the pub/ | directory. Would it be possible to move the files into a separate tzdata/ | directory

Of course, it would be possible, but for now I don't think I'll do that. As much as possible I'd prefer to retain as much of the style of ado's distributions as possible - they were in pub at elsie, the files have also always been in pub on munnari, I think just leaving them in pub on munnari is adequate for now. After all, at least for now, there are just two files (and later perhaps 4 if/when we add detatched signatures).

The oldtz directory is just for us here, no normal humans should be going near it, it is of sudden interest only because people have been (quite well it seems) looking for methods to re-create ado's sccs database (in other version control systems) and so need access to all the earlier data. That's fine (for that purpose, or just to retain it for posterity) but it isn't something that should, or rationally would want, to otherwise be widely distributed.

And lastly Kevin Lyda <kevin@ie.suberic.net> said: | There are several places in the code that refer to the ftp server and | mailing list on elsie.

I suspect the elsie mailing list is dead forever now, and the iana version will take over, so those changes (thanks for the patch) make sense. I'm not sure yet about the source repository doc changes, why not just wait a little longer until we see how the dust settles on that before we start documenting the current (temporary) arrangements ?

kre