I personally _have_ been captain of a ship crossing the Pacific Ocean several years ago. Shipboard clocks were always set to reflect local time when entering territorial waters. And, while we were in international waters, as captain I ordered clocks to be adjusted as we crossed each "natural" longitude-based tz border. Ship-board watches followed official ship's time as ordered by me. (If anyone actually cares, I do have a mini-blog of the trip on- line at http://www.sailblogs.com/member/gentle-wind/ )
-----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Russ Allbery Sent: Friday, May 18, 2012 5:04 PM To: tz@iana.org Subject: Re: [tz] Theory - proposal to delete the reference to population
Tobias Conradi <tobias.conradi@gmail.com> writes:
"If two ships enter territorial waters of HM would the Olson-Eggert- IANA time zone database give them advice for how to set their clocks?"
This is not a sufficiently specified scenario to be analyzable. Missing data includes why they're setting their clocks and what they're trying to coordinate with each other.
Have you been captaining a ship entering those territorial waters and had a specific problem around time zones? If so, please do explain; that would be useful information to have in deciding what the database should do.
If not, I would suggest that this is an artificial, invented problem that may never have occurred and may never become real, at which point the standard best practices of software development kick in. Adding prospective, theoretical database entries to solve problems that we don't fully understand and that have never been specified by someone who is attempting to solve that problem is a bad idea. Such code or data is almost guaranteed to be buggy and wrong when the situation actually arises, since the real world rarely behaves like our preliminary guesses.
Of equal or greater importance as completeness is to decline to state a rule when there is no known rule to state. Artificial accuracy can cause as many problems as missing data.
-- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>