Re: tzid - zones Germany before 1970
Alois Treindl
participate. I prefer not to have too many private discussions when the
questions and answers are of relevance for all contributors to this project.
Please use also the mailing list, unless it is some confidential matter.
Of course you can and should email my privately if you want to send
data, files or images which are not under a open license.
On 08.09.11 14:53, Tobias Conradi wrote:
> Some feedback:
> 1) tzdata-history - I think a better name would be tzdata-pre1970, not
> idea about the "tzdata" part. If only tzdata*.tar.gz is changed then I
> think it is good to have "tzdata" in the name.
It has been named and it is not up to me to rename it.
Not all proposed zones have 'follow zone' statements to point to
standard zones for post-1970, e.g. the proposed Alabama zones cover both
pre- and post-1970 history.
And the discussions here need not be restricted to pre-1970,
contributors here also free to discuss post-1970 questions. Though I
think they should be put into the elsie mailing list.
> 2) australasia_hist 0.01
> Northern territory->Northern Territory
> Lord Howe island->Lord Howe Island
> Gilbert islands->Gilbert Islands
> Chatham islands->Chatham Islands
> Tokelau Islands->Tokelau (That is the country name)
Thanks. But this is all stuff in comments!
> 3) I would only include contributions that have the same license as
> the tz database applies for tzdata.
> I.e. not allowed for inclusion would be:
> http://groups.google.com/group/tzdata-history/browse_thread/thread/d32f9f84af7cf413
I do not agree. tzdata is in the public domain, but CC only requests
'attribution' and allows all kinds of derived works.
tzdata has the habit of always naming the sources in the zone files, and
this is what 'attribution' means. So tzdata can freely include material
published under this CC license.
Anyway, tzdata does not include image files in its distribution, but
your question also can be applied to some zone proposals already
submitted under a CC license. I think the CC license is fine, though I
have made my own submissions so far always public domain.
I think there is a good reason for using CC: some timezone data
collectors and publishers have had the bad habit of not naming their
sources, and then claiming copyright. If such publishers want to use
tzdata fully under public domain, they can continue with their policy.
If attribution is required due to the CC license, they need at least to
mention where they got the data.
> 4) Maps
> I would like polygones given by geographic coordinates. I don't know
> what system to use. But maybe the GPS system (WGS84 etc) is good
> start. So one can at least draw approximate lines on current maps.
I have no opinion yet on this matter. We are busy collection zone data,
boundary definitions via polygons come later.
But I expect that polygons alone are not enough, topology info is
needed, because areas have exclaves and enclaves (holes in them), so the
relation among the polygons must be described. I have never dealt with
such problems in my programming career.
> 5) exclaves, enclaves
> http://groups.google.com/group/tzdata-history/browse_thread/thread/42ad51b5d3d10322
> "Some zones have exclaves and enclaves"
>
> Is that existent in the Olson DB?
of course. Bute the Olson DB gives only rough descriptions of zones,
mostly by naming country or povince names. Countries and provinces have
exclaves and enclaves all the time. Switzerland for example has at least
one German enclave (B�singen) and one Italian enclave (Campione d'Italia).
> 6) "I found a few weaknesses in some post-1970 zones"
> (http://groups.google.com/group/tzdata-history/browse_thread/thread/a66e7e443c4fe8e8)
> This should go to elsie?
I do not know, use your own judgement. I don't know what you mean by
'weaknesses'. If there are errors, Olson and co& are usually very
willing to include fixes quickly.
> 7) zone.tab
> Is there any list of proposed new zones?
> What happens if a pre70 zone is created and later a post70 zone with
> same boundaries but other name is created?
It is work in progress, I think an additional zonetab_hist can easily be
compiled once the history is reasonably complete.
> 8) US, state by state
> http://groups.google.com/group/tzdata-history/browse_thread/thread/d32f9f84af7cf413
>
> What happens if due to using this process zones are created that
> should not, because an adjacent zone in another state has same TZ
> history. Do you know how to handle this? I have no idea how the
> aliases work in zoneinfo.
I worry not about this, because redundancy is not such a great sin if it
helps transparency.
It does not hurt two have two zones America/New_York/New_York and
America/Massachusetts/Boston if the data are organized by state, even
when these two cities in the two states happen to have the same history.
New York state will need over a two hundred zones, its history is
complex, is Shanks' old research is correct, which we will find out.
Massachusetts luckily is simpler, with two zones only (I hope).
For aliases in the zone files there is the LINK syntax. I have given an
example in the comment of my Germany history submission.
Alois Treindl
On 08.09.11 15:28, Alois Treindl wrote:
> Switzerland for example has at least
> one German enclave (B�singen) and one Italian enclave (Campione d'Italia).
I have not proposed extra zones for them in my tzdata contributions
regarding Switzerland.
Update: this needs to be researched.
The current atlas of astro.com has B�singen,D and assigns German rules
to it. And Campione,I and assigns Italian rules.
If that holds up, polygons for both will be needed in the description of
Germany and Italy.
Alois Treindl
with Switzerland.
http://www.videoportal.sf.tv/video?id=c012c029-03b7-4c2b-9164-aa5902cd58d3
But we don't know for 1943 - 1949 and 1916-18.
Tobias Conradi
as defined by the same standard. Maybe you can switch to use an
unambiguous date format.
> > Some feedback:
> > 1) tzdata-history - I think a better name would be tzdata-pre1970, not
> > idea about the "tzdata" part. If only tzdata*.tar.gz is changed then I
> > think it is good to have "tzdata" in the name.
>
> It has been named and it is not up to me to rename it.
> And the discussions here need not be restricted to pre-1970,
> contributors here also free to discuss post-1970 questions. Though I
> think they should be put into the elsie mailing list.
matters here?
> > 2) australasia_hist 0.01
> > Northern territory->Northern Territory
> > Lord Howe island->Lord Howe Island
> > Gilbert islands->Gilbert Islands
> > Chatham islands->Chatham Islands
> > Tokelau Islands->Tokelau (That is the country name)
>
> Thanks. But this is all stuff in comments!
> > 3) I would only include contributions that have the same license as
> > the tz database applies for tzdata.
> > I.e. not allowed for inclusion would be:
> I do not agree. tzdata is in the public domain, but CC only requests
> 'attribution' and allows all kinds of derived works.
>
> tzdata has the habit of always naming the sources in the zone files, and
> this is what 'attribution' means. So tzdata can freely include material
> published under this CC license.
with the CC license mentioned above.
> > 4) Maps
> > I would like polygones given by geographic coordinates. I don't know
> > what system to use. But maybe the GPS system (WGS84 etc) is good
> > start. So one can at least draw approximate lines on current maps.
>
> I have no opinion yet on this matter. We are busy collection zone data,
> boundary definitions via polygons come later.
>
> But I expect that polygons alone are not enough, topology info is
> needed, because areas have exclaves and enclaves (holes in them),
> so the
> relation among the polygons must be described.
> > 5) exclaves, enclaves
> >http://groups.google.com/group/tzdata-history/browse_thread/thread/42...
>
> > Is that existent in the Olson DB?
>
> of course. Bute the Olson DB gives only rough descriptions of zones,
> mostly by naming country or povince names. Countries and provinces have
> exclaves and enclaves all the time. Switzerland for example has at least
> one German enclave (B singen) and one Italian enclave (Campione d'Italia).
> > 6) "I found a few weaknesses in some post-1970 zones"
>
> I do not know, use your own judgement. I don't know what you mean by
> 'weaknesses'.
( http://groups.google.com/group/tzdata-history/msg/8ddf255446825ca2 )
>If there are errors, Olson and co& are usually very
> willing to include fixes quickly.
> > 7) zone.tab
> > Is there any list of proposed new zones?
> > What happens if a pre70 zone is created and later a post70 zone with
> > same boundaries but other name is created?
>
> It is work in progress, I think an additional zonetab_hist can easily be
> compiled once the history is reasonably complete.
of suggested new zones?
> > 8) US, state by state
> > What happens if due to using this process zones are created that
> > should not, because an adjacent zone in another state has same TZ
> > history. Do you know how to handle this? I have no idea how the
> > aliases work in zoneinfo.
>
> I worry not about this, because redundancy is not such a great sin if it
> helps transparency.
> It does not hurt two have two zones America/New_York/New_York and
> America/Massachusetts/Boston if the data are organized by state, even
> when these two cities in the two states happen to have the same history.
Tobias Conradi
Alois Treindl
On 09.09.11 16:36, Tobias Conradi wrote:
>
>
> On Sep 8, 3:28 pm, Alois Treindl<al...@astro.ch> wrote:
>
>> On 08.09.11 14:53, Tobias Conradi wrote:
> It was 2011-09-08 as defined in ISO 8601, not 2008-09-11 or 2011-09-08
> as defined by the same standard. Maybe you can switch to use an
> unambiguous date format.
I am sorry, I don't understand what the issue is. It is a setting in a
mail program which determines how dates are presented. I don't think
this is an issue for tzdata-history.
In zone files for tzdata, the date format is fixed
>>> 3) I would only include contributions that have the same license as
>>> the tz database applies for tzdata.
>>> I.e. not allowed for inclusion would be:
>>> http://groups.google.com/group/tzdata-history/browse_thread/thread/d3...
>>
>> I do not agree. tzdata is in the public domain, but CC only requests
>> 'attribution' and allows all kinds of derived works.
>>
>> tzdata has the habit of always naming the sources in the zone files, and
>> this is what 'attribution' means. So tzdata can freely include material
>> published under this CC license.
> If tzdata is in the public domain it can not at the same time comply
> with the CC license mentioned above.
That is right. Currently the maintainers of tzdata have not declared
that they are willing to include extended history tables. I expect they
have to be collected and maintained externally, for example in this group.
As long as this is the case, it does not matter when there is a mix of
open licenses, as long as they are not more restrictive than the
CC-attribution license.
If Olson wants to include the history zones in his distribution, the
license will have to be nogotiated.
But personally, I propose to use 'public domain' and so far I have
always don so.
>> If there are errors, Olson and co& are usually very
>> willing to include fixes quickly.
> So, why did you email this to tzdata-history then?
because I often duplicate to both mailing lists, which are quite
independent.
>>> 7) zone.tab
>>> Is there any list of proposed new zones?
>>> What happens if a pre70 zone is created and later a post70 zone with
>>> same boundaries but other name is created?
>>
>> It is work in progress, I think an additional zonetab_hist can easily be
>> compiled once the history is reasonably complete.
> That will be when? I.e. how long does one have to wait to see a list
> of suggested new zones?
>
It is work in progress, every new contribution of history zones needs to
define new zone names, and there may be discussion about the choice of
names etc, just like there is a lot of discussion in the elsie mailing
list about new zone names, like currently for West_Bank, Hebron or
East_Jerusalem.
>>> 8) US, state by state
>>> http://groups.google.com/group/tzdata-history/browse_thread/thread/d3...
>>
>>> What happens if due to using this process zones are created that
>>> should not, because an adjacent zone in another state has same TZ
>>> history. Do you know how to handle this? I have no idea how the
>>> aliases work in zoneinfo.
>>
>> I worry not about this, because redundancy is not such a great sin if it
>> helps transparency.
> Is this policy of duplication applied in tzdata (Olson)?
probably not, I do not know. For countries, I think each gets its own
zone, even if another country has the same history. At least I believe
to have seen this for Pacific island states and African states.
>> It does not hurt two have two zones America/New_York/New_York and
>> America/Massachusetts/Boston if the data are organized by state, even
>> when these two cities in the two states happen to have the same history.
> It would be diverging from the tzdata policy.
I think it has to be understood that this mailing list is currently just
a loose assembly of people working mostly in the field of astrology who
see a need of improving historical coverage of tzdata.
This is not a body concerned about formalities. At this stage the most
important thing is that the work is done, not discussions about naming etc.
Zoidiasoft Tech
> define new zone names, and there may be discussion about the choice of
> names etc, just like there is a lot of discussion in the elsie mailing
> list about new zone names, like currently for West_Bank, Hebron or
> East_Jerusalem.
I believe that the Olson standard settled on city names for zones because
countries change more often than cities which leads to more stable
associations. This was a reasonable compromise because Olson stuck to a
1970 horizon and the 500 or so zone names would not be that obscure on the
whole. But to get a "complete" zone history would require thousands of
zones which requires new zone names for towns that will be increasingly
obscure. Since the history is set, sticking to a standard similar to Olson
will be less confusing even if it does not exactly serve the same purpose.
As for the polygon within polygon problem, one can define multiple polygons
to get rid of enclaves and exclaves or do a check to see if a point is in
polygon B (enclave) that is a subset of A...
Sincerely,
Curtis Manwaring