First I'd like to thank Kevin Lyda for taking the time to construct the original tz repository. It is a quite remarkable piece of work. I'm currently looking at a beautifully documented history of the Theory file from the moment Authur created it on 16/2/1987 ... 1987-02-16 in modern money ... The first rule is +* In SVR2, time display in a process is controlled by the environment + variable TZ, which "must be a three-letter time zone name, followed + by a munber representing the difference between local time and + Greenwich Mean Time in hours, followed by an optional three-letter + name for a daylight time zone;" when the optional daylight time zone is + present, "standard U.S.A. Daylight Savings Time conversion is applied." + This means that SVR2 can't deal with other (for example, Australian) + daylight savings time rules, or situations where more than two + time zone abbreviations are used in an area. So it was very much conceived as an 'American' system. Handling other daylight saving offsets or more complex rules was to difficult at that time so ignored. I'll fast forward over the changes which introduced long names to replace the three letter codes, and set up rules about size of population being used to select them. Politics is nothing new and the entire database is an archive of POLITICAL decisions. Until 2001 when a commit was added from a certain Paul Eggert ... +This naming convention is not intended for use by inexperienced users +to select TZ values by themselves (though they can of course examine +and reuse existing settings). Distributors should provide +documentation and/or a simple selection interface that explains the +names; see the 'tzselect' program supplied with this distribution for +one example. And the new rule of + * Uniquely identify every national region where clocks have all + agreed since 1970. This is essential for the intended use: static + clocks keeping local civil time. Does not SPECIFICALLY rule out the gathering of pre 1970 data? It just sets the ground rules for ONE view of the data to be limited. This is about making the data more accessible and was probably the wrong approach even back then. I'll skip the 'frivolity' of adding Mars time in 2004, but it does have relevance to the next step forward. All documented data is valid! http://lsces.org.uk/hg/tz/rev/8a52c38a5f56 is the change that pulls support for specifically 32 bit systems, that note had only JUST been added but is the first reference on scope that I've found? Then finally there is a formal definition of the SCOPE of the database in http://lsces.org.uk/hg/tz/rev/7c18a2e16943 so up until that time data HAS been gathered for the whole of time not just post 1970. I'm more than happy to accept this as the rules for 'TZ' but things have moved on considerably since 1987 and substantially more material is now available and easily accessed to provide insight into all of the documented changes to time standards. So if the 'TZ' distribution is going to ignore that material then we need to set up a 'TZ+' distribution that actively includes all available material. It's not a question it's a statement. Reviewing the Theory file of cause we fall at the first hurdle since the POSIX time format has difficulty coping with some of the intricacies of time management. While encoding a daylight saving change in the time is to be commended, it is only right for a specific period of time. The more accurate approach is purely to identify a 'set of rules' that can be used. This also then automatically covers the provision of leap seconds. What I am saying here is that POSIX is just an implementation detail and while mapping the data to it does require defining, it's not fundamental to the real data. So lets use a standard that is better at handling the modern systems. Obviously I fundamentally disagree with the current scope and that should probably have been disputed in 2011. If one accepts that POSIX is incapable of handling the material, then applying one of it's limitations is also wrong? Since the Calendrical issues section already includes the whole of history, we do have a good base to build on, and are already discussing what 'Universal Time' was prior to 1970. If we can agree that while the validity of some legacy data may be questionably, it is a fact of life that many of these events happened, me just have some uncertainty as to when they happened? I think we can also agree that there is substantial new material which is currently only recorded in notes and which can only enhance the historic record? I'm under no illusion that the problems of manipulating this data into a more usable format is substantial, but it is not impossible. NAMING 'timezones' is the fundamental problem here, and the "This naming convention is not intended for use by inexperienced users" is of fundamental importance here. Mapping rules to usable names is all that is required, so internally in the data we have something suitable for managing the complexity of the problem, while outside a naive user punches in an ISO3166 and gets a timezone suitable for the time frame he is working in. There is a substantial amount of additional history here that could potentially be exposed, such as, for example, ISO3166 codes which have been superseded, or even 'old' TZ names which are now recorded for posterity in archives! The 'backward' file is missing key information on when a particular 'match' was changed, and while dates are not particularly critical, there may be fundamental data provided if one of the legacy names is being reviewed and the CURRENT rule set no longer matches what was being supplied at that time. With hg (or git) I can call up an historic view of backward, and then select a view of the data at that time. Something that one time would have been a substantial amount of work happens in the click of a mouse. DVCS provides a view of the information in a format that relates to how it was entered. That data can be viewed in many other ways if we provide the right tools, that is the key here. 'winnowing' is just one way of manipulating the data, and another would be 'time slicing', providing a snapshot of all the rules active at a particular date. Currently there are a much smaller number of rules active than there were pre-1970, and pre standard time there were an infinite number due to all the different methods of tracking time. During the transition from then until now we have some complex information to map, such as French stations being 5 minutes drift, and UK trains using a different time to the legal system. But if we are looking at times when those rules apply then we need to know that there were differences. There was recorded desention to many summertime changes and this happened in a time where those facts were recorded so that material needs to be made available once it is established. This cuases no end of problems in identifying each area affected, but that's why I brought up the OHM historic mapping. Linking up with that, simple things like historic changes of country names can link us to the appropriate data. This may well require the provision of more than one rule, so that is something that needs handling - with notes if necessary. I've not got as far as I would like and I need to get on, but there is more than enough here already. OK 'TZ' only provides data from 1970 but 'TZ+' would provide all the historic data including the 'TZ' filtered set and additional data within the TZ timeframe. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Lester Caine wrote:
the change that pulls support for specifically 32 bit systems
That change was not about adding or removing support for 32-bit systems, which were (and still are) the most commonly-used tz platform. That change was about improving support for 64-bit systems.
so up until that time data HAS been gathered for the whole of time not just post 1970....
Two things here. First, once we establish the need for a new zone, we attempt to gather high-quality pre-1970 data for it. This doesn't override the guideline that we don't bother to create new zones merely because their timestamps differ before 1970. Second, although the Theory file attempts to document the practices, it often lags because we don't get around to writing everything down. For example my recent proposed patch "Document some longstanding unwritten guidelines." <http://mm.icann.org/pipermail/tz/2013-September/019856.html> says that names cannot end in '/', a guideline that's been faithfully followed since the project began (because the POSIX implementation prohibits names ending in '/') even though nobody got around to writing it down until this month.
finally there is a formal definition of the SCOPE of the database
The guideline about not bothering to create national zones that differ only before 1970 has been in practical use throughout the maintenance of the tz database. In one case (America/Montreal) we departed from it, but that was only because we incorrectly thought that Montreal differed from Toronto in the early 1970s. That timestamp error has been corrected in the data; the extra zone survives only because we didn't want to discard existing data. We would like to allow zones to be added even if they exceed the current guideline. These zones are currently out of scope, and most users won't want them (as they'll be presented with unnecessary choices when selecting TZs, which makes their jobs harder), but a few will want them and if the data are high quality I don't see any reason to exclude from the database. It's just that we need a mechanism for winnowing out these extra zones, as I expect we don't want them installed by default on POSIX platforms. Zefram has proposed one mechanism, we're currently evaluating it, and I hope and expect that it or something like it will appear in the tz database soon. Once that happens, we'll have the mechanism we need, and a place for these new zones.
POSIX is just an implementation detail
Yes and no. Yes, because there are tz parsers and runtimes that run on non-POSIX systems. No, because the restrictions that POSIX imposes are realistic restrictions if we want the code and data to be portable.
On 5 September 2013 13:55, Paul Eggert <eggert@cs.ucla.edu> wrote:
We would like to allow zones to be added even if they exceed the current guideline. These zones are currently out of scope, and most users won't want them (as they'll be presented with unnecessary choices when selecting TZs, which makes their jobs harder), but a few will want them and if the data are high quality I don't see any reason to exclude from the database. It's just that we need a mechanism for winnowing out these extra zones, as I expect we don't want them installed by default on POSIX platforms. Zefram has proposed one mechanism, we're currently evaluating it, and I hope and expect that it or something like it will appear in the tz database soon. Once that happens, we'll have the mechanism we need, and a place for these new zones.
Its important not to forget the existence of non zic parsers here. Adding lots of new data to the current set of files would impact them, forcing them to use all the new IDs or implement their own winnowing. Whereas if the additional zones were placed in a new file "extended", then zic and non-zic consumers could easily choose whether to include the extra data or not. None of the above should stop existing Zone and Link entries from being expanded with researched historic data. ie. pre-1970 data for the existing set of IDs should remain in the main files, unless an entirely new data format is being created (which I'm not enthused about). Stephen
Stephen Colebourne wrote:
Its important not to forget the existence of non zic parsers here.
Yes, we need to keep that in mind.
Whereas if the additional zones were placed in a new file "extended",
Yes, that was in my proposal (since reverted from the experimental repository) and is also in Zefram's, and I expect we'll do something like that.
pre-1970 data for the existing set of IDs should remain in the main files
That doesn't follow. If the main files currently have a link, and we want to turn this into a zone only because of pre-1970 data, we want to keep it a link in the main file, so that we can support existing implementations that are based on the typical current practice.
On 5 September 2013 15:15, Paul Eggert <eggert@cs.ucla.edu> wrote:
pre-1970 data for the existing set of IDs should remain in the main files
That doesn't follow. If the main files currently have a link, and we want to turn this into a zone only because of pre-1970 data, we want to keep it a link in the main file, so that we can support existing implementations that are based on the typical current practice.
I think we agree that most end consumers of the data cannot tell the difference between a Link and a Zone. As such, from their perspective it is very odd to find that some IDs are allowed pre-1970 data and others are not. Furthermore, had someone provided detailed pre-1970 data for America/Aruba a year ago, I think you would have accepted it. Yet you are arguing that now you've made it a Link you can no longer accept it. I would suggest that isn't logical or best practice. Stephen
Stephen Colebourne wrote:
most end consumers of the data cannot tell the difference between a Link and a Zone. As such, from their perspective it is very odd to find that some IDs are allowed pre-1970 data and others are not
If we're talking about the perspective of most end consumers, most of them don't know or care about pre-1970 data. So they won't find anything odd at all.
had someone provided detailed pre-1970 data for America/Aruba a year ago, I think you would have accepted it
No, we've excluded similar pre-1970 data in the past, e.g., Europe/Zagreb.
Paul Eggert wrote:
most end consumers of the data cannot tell the
difference between a Link and a Zone. As such, from their perspective it is very odd to find that some IDs are allowed pre-1970 data and others are not If we're talking about the perspective of most end consumers, most of them don't know or care about pre-1970 data. So they won't find anything odd at all.
The problem with that statement is that 'some' end consumers do. Any application which displays historic data via a timeline ( how far does facebook go back? ) and is switched to use the new way of handling local time will have a problem when scrolling back in time if the calendar displays 'simple GMT times' in one and 'proper local time' in another ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Lester Caine wrote:
'some' end consumers do
Yes, absolutely. We're trying to come up with a solution that caters to the few consumers who really need to know what time it was in Ft. Liard during the solar eclipse of June 10, 1964, without unduly burdening the far greater number of consumers who who don't want to be burdened with information that makes it more of a pain to select TZ settings and that can hurt runtime performance.
Paul Eggert wrote:
'some' end consumers do Yes, absolutely. We're trying to come up with a solution that caters to the few consumers who really need to know what time it was in Ft. Liard during the solar eclipse of June 10, 1964, without unduly burdening the far greater number of consumers who who don't want to be burdened with information that makes it more of a pain to select TZ settings and that can hurt runtime performance.
But what about the mass market example I gave?
Any application which displays historic data via a timeline ( how far does facebook go back? ) and is switched to use the new way of handling local time will have a problem when scrolling back in time if the calendar displays 'simple GMT times' in one and 'proper local time' in another ... If the BROWSER local time zone management is switched to use TZ data properly, then there is a real chance that a lot more people will be hitting historic material via that setting. Currently we have to manually manage local time zone because the browser data is incorrect, and are not using TZ to do it much of the time. With the proposed use in browsers then that will change. Where we have been using TZ for historic calendars and timelines, it's been more by luck than judgement that it's been working at all :(
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Lester Caine wrote:
With the proposed use in browsers then that will change.
I'm afraid that any solution requiring all browsers to agree about time zone data is doomed to failure, for reasons already discussed. My example of the solar eclipse in Ft. Liard in June 19, 1964 was intended to stand as an example of an application needing accurate-to-the-second time stamps for random locations before 1970. You're right that it's not the only example, but the point is that any application that requires these values to be accurate or precise will run into the previously-mentioned problems, independently of all the changes that are being proposed. PS. Perhaps I should mention that as far as Ft. Liard was concerned, the solar eclipse occurred the previous day, and wasn't visible at Ft. Liard. I wouldn't want people to worry about our data quality based just on this example....
Paul Eggert wrote:
My example of the solar eclipse in Ft. Liard in June 19, 1964 was intended to stand as an example of an application needing accurate-to-the-second time stamps for random locations before 1970.
My point is just to get the right hour of the day rather than seconds accuracy initially. This is the real problem with loading the same historic records we are now reading to improve accuracy. While we just log 'local time' without any reference to offsets things are OK, but rationalizing data with respect to 'UTC' requires the stable base that I'm looking for ... for these very historic records. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
On Sep 5, 2013, at 7:57 AM, Lester Caine <lester@lsces.co.uk> wrote:
Paul Eggert wrote:
most end consumers of the data cannot tell the
difference between a Link and a Zone. As such, from their perspective it is very odd to find that some IDs are allowed pre-1970 data and others are not If we're talking about the perspective of most end consumers, most of them don't know or care about pre-1970 data. So they won't find anything odd at all.
The problem with that statement is that 'some' end consumers do. Any application which displays historic data via a timeline ( how far does facebook go back? )
...and do items in the timeline have time stamps for entries created before Facebook existed or do they just have dates? If they just have dates, then Facebook, at least, won't care. If they have times, are they represented as something such as a UTC-based seconds-{before,since}-the-Epoch or are they represented as local time (so that if the user starts their timeline with "Born on March 4, 1957, at 4:27 PM", that's how it's reported to all Facebook users, regardless of what time zone they're in). I think it's non-negotiable that there will be packagers of the tzdb who will winnow out information that requires having different zones for regions that differ only in pre-1970 behavior, and that we will provide a mechanism for them to do so; some consumers do care about pre-1970 data, but if they're running on an OS that winnows out pre-1970 differences, they may have to use their own un-winnowed version of the tzdb.
Guy Harris wrote:
...and do items in the timeline have time stamps for entries created before Facebook existed or do they just have dates? If they just have dates, then Facebook, at least, won't care. If they have times, are they represented as something such as a UTC-based seconds-{before,since}-the-Epoch or are they represented as local time (so that if the user starts their timeline with "Born on March 4, 1957, at 4:27 PM", that's how it's reported to all Facebook users, regardless of what time zone they're in).
If we were just typing in raw information, then there would not be a problem, but having gathered growing volumes of data which includes a lot of accurate time material then normalizing the data to UTC is the next stage to ensure events are correct chronologically across time zones. If the calendar of events is correct in 1970 it should also be connect in 1969 and any year before. My first experience of this was with RECENT calendars where meetings were getting scheduled wrong 6 months later because one application was not bothering with daylight saving and another was ... even though both were storing as UTC. Some of my customers are looking to load archive data beyond the 20 years history we already have and that will go back past 1970, so how do I ensure that normalization of 1970 data will match 1969 stuff? Even just timelining all the material I have related to creating the TZ data needs to have correctly managed offsets for the timeline. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
On Sep 5, 2013, at 11:58 AM, Lester Caine <lester@lsces.co.uk> wrote:
If we were just typing in raw information, then there would not be a problem, but having gathered growing volumes of data which includes a lot of accurate time material then normalizing the data to UTC is the next stage to ensure events are correct chronologically across time zones. If the calendar of events is correct in 1970 it should also be connect in 1969 and any year before. My first experience of this was with RECENT calendars where meetings were getting scheduled wrong 6 months later because one application was not bothering with daylight saving and another was ... even though both were storing as UTC. Some of my customers are looking to load archive data beyond the 20 years history we already have and that will go back past 1970, so how do I ensure that normalization of 1970 data will match 1969 stuff?
By either 1) using your own un-winnowed version of the tzdb or 2) only using systems where the vendor guarantees that they're offering an un-winnowed version of the tzdb, if there are any such systems.
Guy Harris <guy@alum.mit.edu> writes:
By either
1) using your own un-winnowed version of the tzdb
or
2) only using systems where the vendor guarantees that they're offering an un-winnowed version of the tzdb, if there are any such systems.
An obvious approach for distribution packagers would be to provide two packages that both Provide tzdata, one with the traditionally winnowed data (1970 cutoff) and one with the full data, and let people pick. The one winnowed to 1970 would probably be the one installed by default, unless the number of additional zones in the unwinnowed version turned out to not be significant. I suspect that initial installs would provide only the winnowed data for initial time zone selection, since that's where a multitude of choices poses the largest UI concern. One very interesting thing that this proposal offers, which is not currently available, would be to build a custom set of tzdata for the install process that's better-suited to the UI needs of initial installation and time zone selection. For example, for installs, I could see deciding to include only zones whose differences matter for current time (a cutoff of 2013), but including the data set that ensures that every ISO 3166-1 code has at least one zone because the geopolitical issues are particularly acute during the install process. (Of course, one would have to be careful that one didn't drop the selected zone if one switched to a database with a different winnowing property, or provide some mapping mechanism.) -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
Lester Caine wrote:
how do I ensure that normalization of 1970 data will match 1969 stuff?
By not discarding the imported data. If the imported data says the equivalent of "London time", then it should be stored that way, not as GMT. That way, if the time zone tables change, the imported data will be treated consistently with any further data that are imported later. It's unwise to require that time stamp conversion tables be the same on all platforms, and that they never change. That's not feasible for most nontrivial applications. Even if the tz database were perfect and complete for all past time stamps, such a requirement would still go awry with time stamps in the future: if someone now schedules a meeting for October 1, 13:00, Casablanca time, and Morocco changes its rules between now and then, software will mess up after the rule change if it blithely relies on UTC conversions that were computed before the change.
Paul Eggert wrote:
Even if the tz database were perfect and complete for all past time stamps, such a requirement would still go awry with time stamps in the future: if someone now schedules a meeting for October 1, 13:00, Casablanca time, and Morocco changes its rules between now and then, software will mess up after the rule change if it blithely relies on UTC conversions that were computed before the change.
Which is why the location of every event is important, the housekeeping going forward has to take care of the change of time of an event. If this is an international event in Casablanca then all of the other delegates need to be informed of the time change THAT is the reason for normalized times. If it is now an hour earlier or later flight bookings may need changing! Information about the CHANGE is critical for a number of reasons. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Paul's scenario can and I am sure does occur especially in jurisdictions where the timezone changes are only known weeks in advanced from the date they take effect. That's a political problem not a software one. I am sure that the people to whom this really matter (I am thinking the airline industries) probably track this carefully enough and are able to make the needed adjustment to their schedule. But you are right, in order for that to happen correctly both the time and the timezone has to be noted so that a correction can be applied properly. On 05/09/2013 3:48 PM, Lester Caine wrote:
Paul Eggert wrote:
Even if the tz database were perfect and complete for all past time stamps, such a requirement would still go awry with time stamps in the future: if someone now schedules a meeting for October 1, 13:00, Casablanca time, and Morocco changes its rules between now and then, software will mess up after the rule change if it blithely relies on UTC conversions that were computed before the change.
Which is why the location of every event is important, the housekeeping going forward has to take care of the change of time of an event. If this is an international event in Casablanca then all of the other delegates need to be informed of the time change THAT is the reason for normalized times. If it is now an hour earlier or later flight bookings may need changing! Information about the CHANGE is critical for a number of reasons.
-- Oracle Email Signature Logo Patrice Scattolin | Principal Member Technical Staff | 514.905.8744 Oracle WebCenter Mobile applications 600 Blvd de Maisonneuve West Suite 1900 Montreal, Quebec
On Sep 5, 2013, at 1:02 PM, Patrice Scattolin <patrice.scattolin@oracle.com> wrote:
Paul's scenario can and I am sure does occur especially in jurisdictions where the timezone changes are only known weeks in advanced from the date they take effect. That's a political problem not a software one. I am sure that the people to whom this really matter (I am thinking the airline industries) probably track this carefully enough and are able to make the needed adjustment to their schedule. But you are right, in order for that to happen correctly both the time and the timezone has to be noted so that a correction can be applied properly.
As per my mail, the timezone, in the sense of the tzid for a zone, isn't necessarily going to be sufficient if the change involves the location of the event now being in a newly-created tzdb zone. To handle that case automatically will involve an update to a set of machine-readable geographical-coordinates-to-tzid map and the geographical coordinates of the event. (If the event ends up taking place at a location that straddles the tzdb zone boundary after the change, the correct answer might be to cancel the event and boycott that location in future events in order to punish the government for being blithering idiots; you *don't* put a time boundary right through a hotel if you're mentally competent. :-) I'm not going to take seriously concerns about *that* edge case.)
There are family homes, and restaurants in northern Vermont / southern Quebec that have the national boundary line (and hense the tz region) running through the middle of the buildings. (Rock Island Qc/Vt, for example) This is not a big tz issue now since both Montreal & New York follow similiar rules, but it certaily must have been confusing in the 1990s for a few years when their dst rules were different! From Wikipedia: The Tomifobia River <http://en.wikipedia.org/wiki/Tomifobia_River> runs through the town of Stanstead, dividing the U.S./Canadian border at times. Along portions of Canada's Canusa Street <http://en.wikipedia.org/wiki/Canusa_Street>, houses on the southern end of the street lie entirely within Vermont, while their driveways direct northward, and connect to the street in Quebec, as the northern portions of their properties are within Canada. These residents' backyard neighbours are American, while families living right across the street are Canadian, though no noticeable boundary exists between the two (the street itself is entirely within Canada). In other places, the international border runs through individual homes, so that meals prepared in one country are eaten in the other. An entire tool-and-die factory, once operated by the Butterfield division of Litton Industries <http://en.wikipedia.org/wiki/Litton_Industries>, is also divided in two by the border.^[16] <http://en.wikipedia.org/wiki/Stanstead,_Quebec#cite_note-16> On 2013-09-05 16:15, Guy Harris wrote:
you*don't* put a time boundary right through a hotel if you're mentally competent.:-)
--
On Sep 5, 2013, at 1:31 PM, David Patte ₯ <dpatte@relativedata.com> wrote:
There are family homes, and restaurants in northern Vermont / southern Quebec that have the national boundary line (and hense the tz region) running through the middle of the buildings.
...
The Tomifobia River runs through the town of Stanstead, dividing the U.S./Canadian border at times. Along portions of Canada's Canusa Street, houses on the southern end of the street lie entirely within Vermont, while their driveways direct northward, and connect to the street in Quebec, as the northern portions of their properties are within Canada.
So do they have to notify the Canadian Border Services Agency every time they drive onto the street and notify US Immigration and Customs Enforcement every time they drive back into their driveway?
They didn't have to until recently, since everyone in town knew who was american and who was canadian, but their are specific rules in the town now about who has to report and when. I remember passing through there once, and i had to report right in the middle of town. I think I'll phone the town library (which straddles the border) and see how they dealt with the period when the daylight saving rules where different. Maybe it needs a separate tz ID :) On 2013-09-05 16:43, Guy Harris wrote:
On Sep 5, 2013, at 1:31 PM, David Patte ₯ <dpatte@relativedata.com> wrote:
There are family homes, and restaurants in northern Vermont / southern Quebec that have the national boundary line (and hense the tz region) running through the middle of the buildings. ...
The Tomifobia River runs through the town of Stanstead, dividing the U.S./Canadian border at times. Along portions of Canada's Canusa Street, houses on the southern end of the street lie entirely within Vermont, while their driveways direct northward, and connect to the street in Quebec, as the northern portions of their properties are within Canada. So do they have to notify the Canadian Border Services Agency every time they drive onto the street and notify US Immigration and Customs Enforcement every time they drive back into their driveway?
--
On Thu, Sep 5, 2013, at 16:43, Guy Harris wrote:
So do they have to notify the Canadian Border Services Agency every time they drive onto the street and notify US Immigration and Customs Enforcement every time they drive back into their driveway?
There is, in fact, a border post at the end of the street for exactly this purpose, according to this article: http://www.nytimes.com/2007/07/18/world/americas/18border.html
On Sep 5, 2013, at 1:54 PM, random832@fastmail.us wrote:
There is, in fact, a border post at the end of the street for exactly this purpose, according to this article:
http://www.nytimes.com/2007/07/18/world/americas/18border.html
...and, apparently, visits from the police if you don't. The article doesn't address what happens to people who cross the border to get to the dinner table, however. (Speaking of fun with borders, I don't see the strings "Alsace" or "Lorraine" anywhere in the "europe" file. :-))
And, from memory, this was done on purpose with the library straddling the border http://en.wikipedia.org/wiki/Haskell_Free_Library_and_Opera_House From wikipedia http://en.wikipedia.org/wiki/Stanstead,_Quebec The original owners were a couple with dual nationality; Mr. Carlos F. Haskell was an American businessman from Derby Line who owned a number of sawmills, while Mrs. Haskell was born in Canada. The intent was that people on both sides of the border would have use of the facility, which is now a designated historic site. On 05/09/2013 4:31 PM, David Patte ₯ wrote:
From Wikipedia:
The Tomifobia River <http://en.wikipedia.org/wiki/Tomifobia_River> runs through the town of Stanstead, dividing the U.S./Canadian border at times. Along portions of Canada's Canusa Street <http://en.wikipedia.org/wiki/Canusa_Street>, houses on the southern end of the street lie entirely within Vermont, while their driveways direct northward, and connect to the street in Quebec, as the northern portions of their properties are within Canada. These residents' backyard neighbours are American, while families living right across the street are Canadian, though no noticeable boundary exists between the two (the street itself is entirely within Canada). In other places, the international border runs through individual homes, so that meals prepared in one country are eaten in the other. An entire tool-and-die factory, once operated by the Butterfield division of Litton Industries <http://en.wikipedia.org/wiki/Litton_Industries>, is also divided in two by the border.^[16] <http://en.wikipedia.org/wiki/Stanstead,_Quebec#cite_note-16>
On 2013-09-05 16:15, Guy Harris wrote:
you*don't* put a time boundary right through a hotel if you're mentally competent.:-)
--
-- Oracle Email Signature Logo Patrice Scattolin | Principal Member Technical Staff | 514.905.8744 Oracle WebCenter Mobile applications 600 Blvd de Maisonneuve West Suite 1900 Montreal, Quebec
While splitting a timezone could cause an issue, I don't know if in practice that is a common enough problem. A recent example doesn't spring to mind. Sure the W. Bush changes were adopted in pieces and could have caused an issue, I don't remember that in practice that turned out to be a problem that warrants such an involved solution. On 05/09/2013 4:15 PM, Guy Harris wrote:
As per my mail, the timezone, in the sense of the tzid for a zone, isn't necessarily going to be sufficient if the change involves the location of the event now being in a newly-created tzdb zone. To handle that case automatically will involve an update to a set of machine-readable geographical-coordinates-to-tzid map and the geographical coordinates of the event.
(If the event ends up taking place at a location that straddles the tzdb zone boundary after the change, the correct answer might be to cancel the event and boycott that location in future events in order to punish the government for being blithering idiots; you *don't* put a time boundary right through a hotel if you're mentally competent. :-) I'm not going to take seriously concerns about *that* edge case.)
-- Oracle Email Signature Logo Patrice Scattolin | Principal Member Technical Staff | 514.905.8744 Oracle WebCenter Mobile applications 600 Blvd de Maisonneuve West Suite 1900 Montreal, Quebec
Patrice Scattolin wrote:
But you are right, in order for that to happen correctly both the time and the timezone has to be noted so that a correction can be applied properly.
I've never subscribed to including timezone data IN the date, that is always 'UTC' but if the timezone field is 'null' then the location field is used to provide a timezone and the time is assumed to be 'local' to that. As has been said, where systems only return a time offset then time zone has to be calculated a different way anyway. Just spoken to one of my confference customers on another matter and asked them the question on a time change at a venue. The answer was that they would have to maintain the UTC times of the event, both for travel arrangement and also they normally have a live link to another country ... but they hopped that it never happens :) -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Planetwide UTC isn't happening. So having given that up, it's your choice as to how you store the information you need with your calendar. What is clear is that in order to deal automatically with changing DST rules a meeting needs to be coded with it's local timezone known to determine to which meeting a change needs to be made if any. How you do that is an implementation choice. I am not suggesting a change in how dates are exchanged between agents. Both UTC dates and local time dates have their advantages and disadvantages. On 05/09/2013 5:11 PM, Lester Caine wrote:
Patrice Scattolin wrote:
But you are right, in order for that to happen correctly both the time and the timezone has to be noted so that a correction can be applied properly.
I've never subscribed to including timezone data IN the date, that is always 'UTC' but if the timezone field is 'null' then the location field is used to provide a timezone and the time is assumed to be 'local' to that. As has been said, where systems only return a time offset then time zone has to be calculated a different way anyway.
Just spoken to one of my confference customers on another matter and asked them the question on a time change at a venue. The answer was that they would have to maintain the UTC times of the event, both for travel arrangement and also they normally have a live link to another country ... but they hopped that it never happens :)
-- Oracle Email Signature Logo Patrice Scattolin | Principal Member Technical Staff | 514.905.8744 Oracle WebCenter Mobile applications 600 Blvd de Maisonneuve West Suite 1900 Montreal, Quebec
Patrice Scattolin wrote:
I am not suggesting a change in how dates are exchanged between agents. Both UTC dates and local time dates have their advantages and disadvantages.
When managing sites where users log in from around the world, we log all activity using UTC. That is the only way to do it. We then display that information based currently on the timezone they enter in their account profile as we can't do that from their browser information. When an anonymous user logs in we use UTC since we can't display 'local' times based on their browser return in case there IS a change of daylight saving in the calendar period being displayed. The current discussion is how we then handle this normalised data when scrolling the calendar back past 1970 ;) It may not matter if the time is displayed an hour wrong, but it would be nice to be consistent. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
On Fri, Sep 6, 2013, at 16:02, Lester Caine wrote:
When managing sites where users log in from around the world, we log all activity using UTC. That is the only way to do it.
That's fine for logging; the problem is with scheduling future events. If someone schedules a meeting at (e.g.) noon next January, and between now and then the state that meeting takes place in switches from (e.g.) Eastern to Central time, then the program _must not_ move the meeting to eleven. Which means blindly storing the UTC or blindly storing a time+offset is inappropriate.
random832@fastmail.us writes:
If someone schedules a meeting at (e.g.) noon next January, and between now and then the state that meeting takes place in switches from (e.g.) Eastern to Central time, then the program _must not_ move the meeting to eleven. Which means blindly storing the UTC or blindly storing a time+offset is inappropriate.
The obvious common case for this problem is scheduling a recurring meeting at noon in a zone that does a daylight saving switch. Storing the recurring meeting time only in UTC or in zone+offset will obviously not work, since the meeting should not be moving by an hour from the perspective of local time when daylight saving switches happen. I suspect what most people do, and what I've always seen done, is that meeting times are stored as time plus zone identifier and then actual times are recalculated either on display or periodically based on the current rules for that zone identifier. As Guy points out, this still doesn't help if the zone is split or if the locality moves to a different zone, but I've not seen anyone make a serious attempt to handle that case. I think in most places it's rare enough that software isn't written to cope and a human just has to go edit the meetings and fix them. Airlines may have different rules since accuracy in multiple localities and coordination of times across multiple localities is more critical to them than for most meeting and calendaring applications. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
On Fri, Sep 6, 2013, at 16:35, Russ Allbery wrote:
Airlines may have different rules since accuracy in multiple localities and coordination of times across multiple localities is more critical to them than for most meeting and calendaring applications.
Yeah, but if you've got a flight that takes a set amount of time, and one of the endpoints switches zones and the other doesn't, you'd have to reschedule one of them anyway. Airlines are the one place I think it _would_ make sense to schedule everything in UTC. The only situation it wouldn't is if both endpoints make the same change (as when the whole US changed its daylight saving rules). Do we have any airline people here who can comment?
random832@fastmail.us said:
Yeah, but if you've got a flight that takes a set amount of time, and one of the endpoints switches zones and the other doesn't, you'd have to reschedule one of them anyway. Airlines are the one place I think it _would_ make sense to schedule everything in UTC. The only situation it wouldn't is if both endpoints make the same change (as when the whole US changed its daylight saving rules).
Do we have any airline people here who can comment?
Back when you could visit the flight deck on trans-Atlantic flights, I often did so. Sometimes I'd look at the flight planning printout, which gave scheduled times at various checkpoints en route (from memory these are about every 5 degrees of longitude). All times were in Zulu. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
Airlines aren't without their flaws. I did see a flight that was magically 1h shorter than all the others. Reason: DST to ST switchover was occurring during the flight and the reservation system didn't take that into account in their computation of the time of flight. That said, you would think that scheduling is an area where airlines pay particular attention. So it doesn't really matter if you store the meeting time in UTC, local time + TZ or Julian Dates, these are all monotonic. The question is if you have the all the needed information to convert from one form to the next correctly so that this UTC flight time correspond to the correct arrival time in local time. On 06/09/2013 6:03 PM, Clive D.W. Feather wrote:
random832@fastmail.us said:
Yeah, but if you've got a flight that takes a set amount of time, and one of the endpoints switches zones and the other doesn't, you'd have to reschedule one of them anyway. Airlines are the one place I think it _would_ make sense to schedule everything in UTC. The only situation it wouldn't is if both endpoints make the same change (as when the whole US changed its daylight saving rules).
Do we have any airline people here who can comment? Back when you could visit the flight deck on trans-Atlantic flights, I often did so. Sometimes I'd look at the flight planning printout, which gave scheduled times at various checkpoints en route (from memory these are about every 5 degrees of longitude). All times were in Zulu.
-- Oracle Email Signature Logo Patrice Scattolin | Principal Member Technical Staff | 514.905.8744 Oracle WebCenter Mobile applications 600 Blvd de Maisonneuve West Suite 1900 Montreal, Quebec
random832@fastmail.us wrote:
On Fri, Sep 6, 2013, at 16:02, Lester Caine wrote:
When managing sites where users log in from around the world, we log all activity using UTC. That is the only way to do it. That's fine for logging; the problem is with scheduling future events.
If someone schedules a meeting at (e.g.) noon next January, and between now and then the state that meeting takes place in switches from (e.g.) Eastern to Central time, then the program_must not_ move the meeting to eleven. Which means blindly storing the UTC or blindly storing a time+offset is inappropriate.
We already had that discussion yesterday! Check the list archive ;) On the other front ... http://overpass-turbo.eu/s/Zc will take a little while to run when you press 'run' and will show Isle of Man timezone with UK in background. If you pan left, click and slide mouse right, then you will see the boundary between north and south Ireland. The US areas are giving me a time out as they are too big. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
On Fri, Sep 6, 2013, at 16:50, Lester Caine wrote:
On the other front ... http://overpass-turbo.eu/s/Zc will take a little while to run when you press 'run' and will show Isle of Man timezone with UK in background. If you pan left, click and slide mouse right, then you will see the boundary between north and south Ireland. The US areas are giving me a time out as they are too big.
You can get three or four states at a time - they don't seem to have any data for Indiana (Ohio and Illinois loaded around it) Is there a way to get it to run on a dataset consisting of only countries, states, and counties (and equivalent divisions of other countries), I'm wondering if the reason it takes so long is because it's searching through every little parking lot.
On Sep 5, 2013, at 12:48 PM, Lester Caine <lester@lsces.co.uk> wrote:
Which is why the location of every event is important, the housekeeping going forward has to take care of the change of time of an event. If this is an international event in Casablanca then all of the other delegates need to be informed of the time change THAT is the reason for normalized times. If it is now an hour earlier or later flight bookings may need changing! Information about the CHANGE is critical for a number of reasons.
As you note, the location of every event is important, so any database of events that needs to compensate for time shifts would need to keep the location of the event - in some form *other* than a tzid, in case the time shift is due to a regional split and the event is now in a region with a *different* tzid - and keep a UTC version of the event date/time (and perhaps also the local time version) and, when the software is informed that the tzdb has changed, re-determine the local time and inform the attendees that the local time is different. The only information about the change that's needed there is that the change happened.
Paul Eggert wrote:
pre-1970 data for
the existing set of IDs should remain in the main files That doesn't follow. If the main files currently have a link, and we want to turn this into a zone only because of pre-1970 data, we want to keep it a link in the main file, so that we can support existing implementations that are based on the typical current practice.
Isn't this exactly the situation I've just hit? How do I get that information in. Is there any problem with adding extra RULES in the relevant file if that is what is needed to complete the picture? Identifying additional rules is always going to be a problem, but may well be using other data from the same file? It's the VISIBILITY of these additional identifiers which is the problem. Is there no way to add something which existing zic scripts will simply ignore. Personally I'd prefer that was timestamps, but perhaps we have to resort to commented lines with a special purpose? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Lester Caine wrote:
Isn't this exactly the situation I've just hit?
Yes that's right.
Is there any problem with adding extra RULES in the relevant file
No, Rule lines are not the problem, since they're not copied into zic's output. It's the Zone and Link lines that are the problem.
It's the VISIBILITY of these additional identifiers which is the problem.
Yes, visibility is a problem, but it's not the only problem. We also have data bloat even if the set of identifiers remains the same, because turning a link into a zone has a runtime expense.
Is there no way to add something which existing zic scripts will simply ignore.
There isn't one now really, other than putting the data into a different source file and not telling zic about that source file. Zefram's proposal would introduce a better way to do that, and this is the sort of thing that I expect will be needed before we can open the floodgates.
On 2013-09-05 08:52, Paul Eggert wrote:
Yes, visibility is a problem, but it's not the only problem. We also have data bloat even if the set of identifiers remains the same, because turning a link into a zone has a runtime expense.
Build time and ~4KB file storage expense, no runtime difference, other than the overhead of accessing via a link (on distros which support links, and use them). The storage overhead is negligible for most as host distros provide both posix and right alternatives. For perspective, total source data is <800KB, binary data <800KB for POSIX, <1100KB for right.
On 2013-09-05 08:52, Paul Eggert wrote:
Lester Caine wrote:
Is there no way to add something which existing zic scripts will simply ignore.
There isn't one now really, other than putting the data into a different source file and not telling zic about that source file. Zefram's proposal would introduce a better way to do that, and this is the sort of thing that I expect will be needed before we can open the floodgates.
I would like to suggest that if historical zone changes can not be accomodated in the main zone files, perhaps they should be added as zone entries in the (optional) *backward* file, overriding links in either file. If we can support historical leap seconds, so that scientists can correlate past data to the second, we should also try to support historians, genealogists, astrologers, and others who care about past times, as well as the travel industry who care about current and future times. Oh, and the sys admins who care their systems show the correct time to all users, where and when ever they may be. Why folks give a damn about hours here or there years ago, I can not fathom, but unforeseen and unintended creative uses of applications and data can often dwarf the original intent, if the work is done well, as it obviously has been, otherwise you would not get such a furor.
Brian Inglis wrote:
I would like to suggest that if historical zone changes can not be accomodated in the main zone files, perhaps they should be added as zone entries in the (optional) *backward* file, overriding links in either file.
Yes, that's the sort of thing we should be looking at. Perhaps not 'backward' itself, as with the current zic implementation links overrides zones; but some other file like 'backward'. This in in both my proposal (since reverted) and Zefram's, and I'm confident that we'll get it to work somehow.
It seems, based on the discussions, that one desired feature of an "extended" notation is to be able to say "this zone is like that other zone during period X." Herein, a suggestion for notation to express that relation: In a line of the zone record, the GMTOFF, RULES, and FORMAT fields may consist of an equal sign followed by the name of a zone. This has the meaning "use the data for the named zone in this zone as well." An equal sign standing alone repeats the most recent zone explicitly named in an equals-reference (which must be within the current zone record). Examples, using zones already in the database, follow: Zone America/North_Dakota/New_Salem -6:45:39 - LMT 1883 Nov 18 12:14:21 -7:00 US M%sT 2003 Oct 26 02:00 -6:00 US C%sT would in this notation be expressed as Zone America/North_Dakota/New_Salem -6:45:39 - LMT 1883 Nov 18 12:14:21 =America/Denver = = 2003 Oct 26 02:00 =America/Chicago = = And America/Shiprock could be represented as Zone America/Shiprock =America/Denver = NNT (meaning that it always follows Denver's offset and DST rules, but uses the abbreviation NNT--the phrase "Navajo Nation Time" is in use).
I like the idea of an extended zic notation; this is the sort of thing that I was asking for, expressed more elegantly than I hoped. Can you or someone else volunteer to implement it?
"I like the idea of an extended zic notation; this is the sort of thing that I was asking for, expressed more elegantly than I hoped. Can you or someone else volunteer to implement it?" Unfortunately, I don't speak C. I can take it as far as an algorithm, maybe even pseudocode, but will need another person to make working C code of it.
On 2013-09-05 15:46, Andy Lipscomb wrote:
It seems, based on the discussions, that one desired feature of an "extended" notation is to be able to say "this zone is like that other zone during period X." Herein, a suggestion for notation to express that relation:
In a line of the zone record, the GMTOFF, RULES, and FORMAT fields may consist of an equal sign followed by the name of a zone. This has the meaning "use the data for the named zone in this zone as well." An equal sign standing alone repeats the most recent zone explicitly named in an equals-reference (which must be within the current zone record).
Examples, using zones already in the database, follow:
Zone America/North_Dakota/New_Salem -6:45:39 - LMT 1883 Nov 18 12:14:21 -7:00 US M%sT 2003 Oct 26 02:00 -6:00 US C%sT
would in this notation be expressed as
Zone America/North_Dakota/New_Salem -6:45:39 - LMT 1883 Nov 18 12:14:21 =America/Denver = = 2003 Oct 26 02:00 =America/Chicago = =
And America/Shiprock could be represented as
Zone America/Shiprock =America/Denver = NNT
(meaning that it always follows Denver's offset and DST rules, but uses the abbreviation NNT--the phrase "Navajo Nation Time" is in use).
I guess such =zone references should refer to a zone earlier in the same file to keep things simple, i.e. no forward or external references. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
"I guess such =zone references should refer to a zone earlier in the same file to keep things simple, i.e. no forward or external references." Not an absolute logical necessity, but certainly a safe way to do things. It does have implications in the design of the extended files, in that they would need to be supersets of the basic files, not supplemental files used in conjunction with them. In the alternative, a limited form of import could be allowed in that a file named (for exampile) "kalimdor-extended" would be allowed to reference the zones of the file "kalimdor" as well as the ones it contains itself.
On 2013-09-05 17:52, Andy Lipscomb wrote:
"I guess such =zone references should refer to a zone earlier in the same file to keep things simple, i.e. no forward or external references."
Not an absolute logical necessity, but certainly a safe way to do things. It does have implications in the design of the extended files, in that they would need to be supersets of the basic files, not supplemental files used in conjunction with them. In the alternative, a limited form of import could be allowed in that a file named (for exampile) "kalimdor-extended" would be allowed to reference the zones of the file "kalimdor" as well as the ones it contains itself.
I suppose there's no harm in allowing external references as long as those are parsed first, treating the concatenation of the files (or a subset of the files, e.g. excluding the "extended" zones) as "one big file". This means you could only run zic on a self-consistent list of files ordered to not have no forward references. Another possibility would be to have an "Include" directive containing a relative pathname (relative to the file containing the "Include" directive) to another file. Then "kalimdor-extended" could contain the line: Include kalimdor to include the non-extended zones before it defines the extended zones. Then zic could be run on either kalimdor or kalimdor-extended, but not both, since the latter includes the former automatically. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
On Thu, Sep 5, 2013, at 13:12, Ian Abbott wrote:
Include kalimdor
to include the non-extended zones before it defines the extended zones. Then zic could be run on either kalimdor or kalimdor-extended, but not both, since the latter includes the former automatically.
What about a require/import statement, which parses the given filename but does not generate output? This would also allow us to centralize Rules that are used in more than one file.
<From: random832@fastmail.us [mailto:random832@fastmail.us] <Sent: Thursday 05 September 2013 13:30 < <On Thu, Sep 5, 2013, at 13:12, Ian Abbott wrote: <> Include kalimdor <> <> to include the non-extended zones before it defines the extended zones. <> Then zic could be run on either kalimdor or kalimdor-extended, but <> not both, since the latter includes the former automatically. < <What about a require/import statement, which parses the given filename but does not generate output? < <This would also allow us to centralize Rules that are used in more than one file. Hmm... this is getting into details of how-the-compiler-works that require more knowledge than I have of the wizardry. As such, I have to write on a slightly more abstract level, but as I see it, there are two key things that have to be avoided, both of which already exist (in simpler form) for links: a reference pointing to a nonexistent zone, or a circular reference. Also a note with respect to winnowing: if all transitions in a zone are before the cutoff date, and the last line is a straight single reference (=zone = =), then the zone is equivalent to a link.
On 2013-09-05 17:43, Ian Abbott wrote:
On 2013-09-05 15:46, Andy Lipscomb wrote:
It seems, based on the discussions, that one desired feature of an "extended" notation is to be able to say "this zone is like that other zone during period X." Herein, a suggestion for notation to express that relation:
In a line of the zone record, the GMTOFF, RULES, and FORMAT fields may consist of an equal sign followed by the name of a zone. This has the meaning "use the data for the named zone in this zone as well." An equal sign standing alone repeats the most recent zone explicitly named in an equals-reference (which must be within the current zone record).
Examples, using zones already in the database, follow:
Zone America/North_Dakota/New_Salem -6:45:39 - LMT 1883 Nov 18 12:14:21 -7:00 US M%sT 2003 Oct 26 02:00 -6:00 US C%sT
would in this notation be expressed as
Zone America/North_Dakota/New_Salem -6:45:39 - LMT 1883 Nov 18 12:14:21 =America/Denver = = 2003 Oct 26 02:00 =America/Chicago = =
And America/Shiprock could be represented as
Zone America/Shiprock =America/Denver = NNT
(meaning that it always follows Denver's offset and DST rules, but uses the abbreviation NNT--the phrase "Navajo Nation Time" is in use).
I guess such =zone references should refer to a zone earlier in the same file to keep things simple, i.e. no forward or external references.
I also forgot to add that this =zone thing would also make the Link directive redundant, since a zone line of the form: Zone Asia/Calcutta =Asia/Kolkata = = could be treated the same as: Link Asia/Kolkata Asia/Calcutta -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
Ian Abbott wrote:
I guess such =zone references should refer to a zone earlier in the same file to keep things simple
But order is not supposed to matter in zic input. The man page says "Except for continuation lines, lines may appear in any order in the input." It's probably better to continue in that tradition, even if it's a bit harder to implement. I think it'd be OK if the new "extended" file is not treated as if it could be compiled by itself. I've often chafed at the current approach, where we for example need to copy rules from other files into "antarctica"; I'd rather avoid copies in the data, as they're harder to maintain.
Paul Eggert said:
I guess such =zone references should refer to a zone earlier in the same file to keep things simple
But order is not supposed to matter in zic input. The man page says "Except for continuation lines, lines may appear in any order in the input." It's probably better to continue in that tradition, even if it's a bit harder to implement.
Right. We are long past the days when forward references were hard to compute. The computer can do the work of a two-pass algorithm if it has to. Make it easy for users to write rather than forcing arbitrary-looking rules. (There are algorithms for detecting loops, so that's not an argument either.) -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
On 2013-09-05 18:24, Paul Eggert wrote:
Ian Abbott wrote:
I guess such =zone references should refer to a zone earlier in the same file to keep things simple
But order is not supposed to matter in zic input. The man page says "Except for continuation lines, lines may appear in any order in the input." It's probably better to continue in that tradition, even if it's a bit harder to implement.
I think it'd be OK if the new "extended" file is not treated as if it could be compiled by itself. I've often chafed at the current approach, where we for example need to copy rules from other files into "antarctica"; I'd rather avoid copies in the data, as they're harder to maintain.
Rather than extending the current zic format, would it make more sense to have a preprocessor that produces files that can be fed to zic or to third-party "zic file" parsers? The preprocessor could pull in rules that are shared between files, for example. It could even do the winnowing of data that has been talked about. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
Ian Abbott wrote:
Rather than extending the current zic format, would it make more sense to have a preprocessor that produces files that can be fed to zic or to third-party "zic file" parsers?
That'd be "as well as". The input to the preprocessor would be an extended version of the zic format. I think we should indeed have something that can turn extended-zic source into old-zic source, for the benefit of third parties that have their own zic equivalent. But edge cases around transition times being specified in different ways mean that it's not straightforward to resolve "=" items to the underlying zone behaviour. You have to decide whether "02:00u" comes before "01:00" (local), for example. Doing it correctly requires quite a lot of zic's understanding of the data. So the preprocessor to generate old-style zic source would actually be our zic with an option telling it to act as the preprocessor.
even do the winnowing of data that has been talked about.
That wouldn't work so well. Resolving the winnowing requires computing all the observances and transitions, which is zic's job, so you'd have to incorporate zic into the "preprocessor", at which point it isn't "pre" any more. Even more so than "=" resolution, this requires full zic. As it is, we can reasonably easily implement source winnowing around the tzwinnow program, which operates from the tzfiles. For completeness, we can also implement a program that turns a tzfile into zic source. Of course, its synthetic DST rules wouldn't bear much resemblance to the original zic source, so Stephen wouldn't be happy with it. It wouldn't be an adequate solution to turning "="-enabled extended-zic source into old-zic source. But it may be useful in some strange set of circumstances. -zefram
On 5 September 2013 15:08, Stephen Colebourne <scolebourne@joda.org> wrote:
On 5 September 2013 13:55, Paul Eggert <eggert@cs.ucla.edu> wrote: Its important not to forget the existence of non zic parsers here. Adding lots of new data to the current set of files would impact them, forcing them to use all the new IDs or implement their own winnowing.
Whereas if the additional zones were placed in a new file "extended", then zic and non-zic consumers could easily choose whether to include the extra data or not.
None of the above should stop existing Zone and Link entries from being expanded with researched historic data. ie. pre-1970 data for the existing set of IDs should remain in the main files, unless an entirely new data format is being created (which I'm not enthused about).
Just to outline my needs from the dataset: - the full time-zone history for all IDs currently in the "main" files - the old IDs located in the "backward" file The current way of working appears to be is: - the full time-zone history for all Zones currently in the "main" files - no time-zone history for Links currently in the "main" files - the old IDs located in the "backward" file Note that the only IDs I need are those IDs that are currently deemed important enough to be in the current tzdb. I don't need any more IDs, or any more accurate history for locations (such as the difference between Paris and Lyon). I do need full history, if available, for IDs currently defined as Link entries. The discussion is proposing a variety of extensions and file format changes, but to actually achieve the minimal extension outlined above will require parsing and understanding the full set of extended data. My preferred solution would be to allow Link entries to be converted to Zone entries if and when the history becomes available. With a winnowing solution, this would have no impact on data sizes or performance AFAICT. Summary, there is a middle ground between not caring about pre-1970 and caring about everything. I don't want the need for that middle ground to be lost. Stephen
participants (13)
-
Andy Lipscomb -
Brian Inglis -
Clive D.W. Feather -
David Patte ₯ -
Guy Harris -
Ian Abbott -
Lester Caine -
Patrice Scattolin -
Paul Eggert -
random832＠fastmail.us -
Russ Allbery -
Stephen Colebourne -
Zefram