suggestion: split "backward" into "backward" and "deprecated"
In a post on this list on Nov 24 last, Garret Wollman said regarding FreeBSD's c.1994 change (now reversed) to not install "backward":
I chose not to install the "backward" zones in the hope that this would more securely deprecate the then-recently-obsoleted old-style names like "US/Eastern", and then maybe they could be completely removed from the distribution if other downstream consumers (only a few operating systems at that point, no language runtimes) would do likewise.
Unfortunately, these ancient compatibility links never got deleted, so "backward" now contains a mix of ancient and more recent compatibility links, and users are still using them (or being told to use them by documentation that should have been updated decades ago).
The obvious way to resolve this would be to split "backward" into two: one file containing aliases that were once regarded as canonical names (or at least names consistent with current naming theory) but were then renamed (e.g. the recent example of Godthab -> Nuuk), the other containing all the ancient stuff that never conformed to the current style (such as "W-SU", "Poland", "GB-Eire", "US/Eastern" etc.). One way to do this might be to set a cutoff date, for which the 2000a data release seems like a good choice, and retain only the zones changed since then in "backward", moving the remainder to a new "deprecated" category. Another way would be to reserve "backward" for zones that have appeared in zone.tab at any time, and move the rest to "deprecated". It turns out that these two methods give almost exactly the same results, with only two exceptions: America/Ensenada was in "backward" before 2000 going by the SCM history, but existed in zone.tab until 2010; and Asia/Ulan_Bator was added to "backward" and removed from zone.tab in the 2000a release. This suggests that the zone.tab criterion is a slightly better one. (One further exception should be made: the link from Etc/UTC to UTC is in widespread use and should probably be moved to "etcetera" alongside the similar "GMT" link. Otherwise it should stay in "backward". This change already exists in FreeBSD, where all "GMT" defaults have been changed to "UTC" at some point.) Split this way, the list of links in "backward" would become (posted in plain text here for readability, I can submit in patch form if needed) as follows: Link Africa/Nairobi Africa/Asmera Link Africa/Abidjan Africa/Timbuktu Link America/Argentina/Catamarca America/Argentina/ComodRivadavia Link America/Argentina/Buenos_Aires America/Buenos_Aires Link America/Argentina/Catamarca America/Catamarca Link America/Atikokan America/Coral_Harbour Link America/Argentina/Cordoba America/Cordoba Link America/Tijuana America/Ensenada Link America/Nuuk America/Godthab Link America/Indiana/Indianapolis America/Indianapolis Link America/Argentina/Jujuy America/Jujuy Link America/Kentucky/Louisville America/Louisville Link America/Argentina/Mendoza America/Mendoza Link America/Toronto America/Montreal Link America/Rio_Branco America/Porto_Acre Link America/Argentina/Cordoba America/Rosario Link America/Tijuana America/Santa_Isabel Link America/Denver America/Shiprock Link Pacific/Auckland Antarctica/South_Pole Link Asia/Ashgabat Asia/Ashkhabad Link Asia/Kolkata Asia/Calcutta Link Asia/Shanghai Asia/Chongqing Link Asia/Shanghai Asia/Chungking Link Asia/Dhaka Asia/Dacca Link Asia/Shanghai Asia/Harbin Link Asia/Urumqi Asia/Kashgar Link Asia/Kathmandu Asia/Katmandu Link Asia/Macau Asia/Macao Link Asia/Yangon Asia/Rangoon Link Asia/Ho_Chi_Minh Asia/Saigon Link Asia/Thimphu Asia/Thimbu Link Asia/Makassar Asia/Ujung_Pandang Link Asia/Ulaanbaatar Asia/Ulan_Bator Link Atlantic/Faroe Atlantic/Faeroe Link Europe/Oslo Atlantic/Jan_Mayen Link Etc/UTC Etc/UCT Link Europe/London Europe/Belfast Link Europe/Chisinau Europe/Tiraspol Link Pacific/Honolulu Pacific/Johnston Link Pacific/Pohnpei Pacific/Ponape Link Pacific/Chuuk Pacific/Truk Link Pacific/Chuuk Pacific/Yap Link Etc/UTC UTC "deprecated" would contain these links: Link America/Adak America/Atka Link America/Indiana/Indianapolis America/Fort_Wayne Link America/Indiana/Knox America/Knox_IN Link America/Port_of_Spain America/Virgin Link Asia/Jerusalem Asia/Tel_Aviv Link Australia/Sydney Australia/ACT Link Australia/Sydney Australia/Canberra Link Australia/Lord_Howe Australia/LHI Link Australia/Sydney Australia/NSW Link Australia/Darwin Australia/North Link Australia/Brisbane Australia/Queensland Link Australia/Adelaide Australia/South Link Australia/Hobart Australia/Tasmania Link Australia/Melbourne Australia/Victoria Link Australia/Perth Australia/West Link Australia/Broken_Hill Australia/Yancowinna Link America/Rio_Branco Brazil/Acre Link America/Noronha Brazil/DeNoronha Link America/Sao_Paulo Brazil/East Link America/Manaus Brazil/West Link America/Halifax Canada/Atlantic Link America/Winnipeg Canada/Central Link America/Toronto Canada/Eastern Link America/Edmonton Canada/Mountain Link America/St_Johns Canada/Newfoundland Link America/Vancouver Canada/Pacific Link America/Regina Canada/Saskatchewan Link America/Whitehorse Canada/Yukon Link America/Santiago Chile/Continental Link Pacific/Easter Chile/EasterIsland Link America/Havana Cuba Link Africa/Cairo Egypt Link Europe/Dublin Eire Link Europe/London GB Link Europe/London GB-Eire Link Etc/GMT GMT+0 Link Etc/GMT GMT-0 Link Etc/GMT GMT0 Link Etc/GMT Greenwich Link Asia/Hong_Kong Hongkong Link Atlantic/Reykjavik Iceland Link Asia/Tehran Iran Link Asia/Jerusalem Israel Link America/Jamaica Jamaica Link Asia/Tokyo Japan Link Pacific/Kwajalein Kwajalein Link Africa/Tripoli Libya Link America/Tijuana Mexico/BajaNorte Link America/Mazatlan Mexico/BajaSur Link America/Mexico_City Mexico/General Link Pacific/Auckland NZ Link Pacific/Chatham NZ-CHAT Link America/Denver Navajo Link Asia/Shanghai PRC Link Pacific/Pago_Pago Pacific/Samoa Link Europe/Warsaw Poland Link Europe/Lisbon Portugal Link Asia/Taipei ROC Link Asia/Seoul ROK Link Asia/Singapore Singapore Link Europe/Istanbul Turkey Link Etc/UTC UCT Link America/Anchorage US/Alaska Link America/Adak US/Aleutian Link America/Phoenix US/Arizona Link America/Chicago US/Central Link America/Indiana/Indianapolis US/East-Indiana Link America/New_York US/Eastern Link Pacific/Honolulu US/Hawaii Link America/Indiana/Knox US/Indiana-Starke Link America/Detroit US/Michigan Link America/Denver US/Mountain Link America/Los_Angeles US/Pacific Link Pacific/Pago_Pago US/Samoa Link Etc/UTC Universal Link Europe/Moscow W-SU Link Etc/UTC Zulu -- Andrew.
On Mon, 4 May 2020, Andrew Gierth wrote: ... >8
Another way would be to reserve "backward" for zones that have appeared in zone.tab at any time, and move the rest to "deprecated".
... >8
(One further exception should be made: the link from Etc/UTC to UTC is
I tried to get UTC added to zone.tab back on 9 Mar 2016; but received a lot of push back. Everyone seemed to be hung up on the use-case definition that UTC is an enigma, existing everywhere and nowhere at the same time. Heads exploded at the thought of UTC having a geographic connection, which it does. Enumerating that connection in no way inhibits the enigma use-case, IMO. It is incomprehensible to me that a database built around a single reference, makes that reference unreachable from within, for lack of better a term, its API. There are many projects, both hardware and software, that use zone.tab as the Time Zone Database API. For these projects, if it's not in zone.tab it does not exist. For example, in my GPS hardware I'm forced to use Reykjavik for UTC. The geographic tie is just a API lookup index, any zone can be used at any location. If I'm in Tokyo, I can still use the New York zone, even though that zone has a North American geographic tie. UTC having a geographic tie doesn't in anyway inhibit its global use. Another complaint was that a single locale is not a zone. The DB already contains single point 'zones' in Antarctica, which are in zone.tab. ... >8
-- Andrew.
On 2020-05-03 20:36, Andrew Gierth wrote:
(One further exception should be made: the link from Etc/UTC to UTC is in widespread use and should probably be moved to "etcetera" alongside the similar "GMT" link. Otherwise it should stay in "backward". This change already exists in FreeBSD, where all "GMT" defaults have been changed to "UTC" at some point.)
It is not clear what you mean by saying FreeBSD changed GMT defaults to UTC at some point. There is a subtle distinction here as legal time in English common law derived legal systems is established by precedent, as GMT based mean solar time, not on the ITU time scale based on the SI second with leap seconds UTC. The difference between the legal basis of time derived from solar observations and calculations, and the practice of disseminating time derived from UTC, has not yet been tested in law, so dropping any distinction could be problematic, especially now, with GB divorcing EU, to give English common law renewed hegemony over GB laws in devolved assemblies, except for NI as regards time. The statute in primary effect in England, Wales, and Scotland is still: http://statutes.org.uk/site/the-statutes/nineteenth-century/1880-43-44-victo... and it also currently pertains to NI, Isle of Man, the Channel Islands of Jersey, Guernsey, Alderney, Sark; and by reference to GMT (often in local equivalents of Interpretation, or Definition of Time, Acts), also to Ireland, Belgium, Portugal, Canaries, Iceland, Faeroes, Canada, and a number of African former territories of the British Empire and current members of the Commonwealth (of Nations). -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.
"Brian" == Brian Inglis <Brian.Inglis@SystematicSw.ab.ca> writes:
(One further exception should be made: the link from Etc/UTC to UTC is in widespread use and should probably be moved to "etcetera" alongside the similar "GMT" link. Otherwise it should stay in "backward". This change already exists in FreeBSD, where all "GMT" defaults have been changed to "UTC" at some point.)
Brian> It is not clear what you mean by saying FreeBSD changed GMT Brian> defaults to UTC at some point. I mean that where the tzcode uses "GMT" as a default zone name or abbreviation in the absence of data, FreeBSD uses "UTC" (and has since 2004). e.g. with no /etc/localtime file, % env -u TZ date Tue 5 May 2020 00:00:37 UTC (To the best of my knowledge there are no reference clocks available to which one could synchronize in order to use a mean solar time, so your argument seems to me to support this choice.) -- Andrew.
On 5/4/20 5:26 PM, Andrew Gierth wrote:
I mean that where the tzcode uses "GMT" as a default zone name or abbreviation in the absence of data, FreeBSD uses "UTC" (and has since 2004).
It would be easy enough to replace the "GMT" in localtime.c and the "TZ=GMT0" in date.c with their UTC counterparts. This issue is somewhat independent of what's in 'backward', though, because this stuff is hard-coded in tzcode and tzdata's contents don't affect it. Getting back to the main point, I'm not sure it's worth deprecating links like 'US/Pacific' any time soon, as so many people use them and their cost is not great. It might be worth coming up with some division of the existing 'backward' file (e.g., recently-backward names vs older-backward names), although I'm not sure what that would look like. I suppose we could have a comment associated with each name saying when it became backward, though that'd increase maintenance hassle.
On 2020-05-05 08:46:52 (+0800), Paul Eggert wrote:
Getting back to the main point, I'm not sure it's worth deprecating links like 'US/Pacific' any time soon, as so many people use them and their cost is not great.
As far as FreeBSD is concerned: since we haven't installed 'US/Pacific' since ca 1994, I'm pretty sure nobody uses it. :-) Since you mention cost though: installing the backward zones increased the footprint of /usr/share/zoneinfo from about 1.8M to about 3.3M. I don't consider that worth losing sleep over in 2020. People who build systems where every megabyte counts probably don't ship /usr/share/zoneinfo in the first place. Or they can trivially patch the build system not to install backward zones.
It might be worth coming up with some division of the existing 'backward' file (e.g., recently-backward names vs older-backward names), although I'm not sure what that would look like. I suppose we could have a comment associated with each name saying when it became backward, though that'd increase maintenance hassle.
Adding a comment stating when the name became backward isn't a huge additional maintenance burden. Especially since we don't move things to backward all that often. The division into backward and deprecated could be scripted based on that comment. Adding the historical comments would be a bit of work though. We could also split backward as Andrew proposes and start tagging additions to backward going forward. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
"Philip" == Philip Paeps <philip@trouble.is> writes:
Philip> Since you mention cost though: installing the backward zones Philip> increased the footprint of /usr/share/zoneinfo from about 1.8M Philip> to about 3.3M. Really? Installing "backward" should create only links, and therefore have negligible effect on the size, the only real penalty being the extra directories and entries which should be only a few blocks at most. Philip> Or they can trivially patch the build system not to install Philip> backward zones. Well, there used to be a build option for that in the base system, but somebody just took it out... -- Andrew.
On 2020-05-05 11:00:18 (+0800), Andrew Gierth wrote:
Philip Paeps <philip@trouble.is> wrote:
Since you mention cost though: installing the backward zones increased the footprint of /usr/share/zoneinfo from about 1.8M to about 3.3M.
Really?
Installing "backward" should create only links, and therefore have negligible effect on the size, the only real penalty being the extra directories and entries which should be only a few blocks at most.
It looks like we install the files rather than links. Or I've botched something on the test machine I looked at (which is not unlikely).
Or they can trivially patch the build system not to install backward zones.
Well, there used to be a build option for that in the base system, but somebody just took it out...
Easy enough to put back if someone yells about it. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
On 5/4/20 8:16 PM, Philip Paeps wrote:
It looks like we install the files rather than links. Or I've botched something on the test machine I looked at (which is not unlikely).
If you're installing files then that should get fixed. In tzdb on my Fedora 31 platform (ext4 filesystem with 4 KiB blocks), 'make install' creates a zoneinfo directory that 'du' reports consumes 1800 KiB, as opposed to the 1776 KiB consumed for the same directory with 'make BACKWARD="" install'. The 24 KiB difference comes mostly from the five extra directories implied by 'backward' (Brazil, Canada, Chile, Mexico, US) each of which consume 4 KiB; the rest comes from the larger tzdata.zi file (108 vs 112 KiB allocated, due to the extra -L lines).
Or they can trivially patch the build system not to install backward zones.
Well, there used to be a build option for that in the base system, but somebody just took it out...
Easy enough to put back if someone yells about it.
Might make sense to put it back in (if only for compatibility with older FreeBSD systems where TZ='W-SU' gave you UTC :-).
"Paul" == Paul Eggert <eggert@cs.ucla.edu> writes:
Or they can trivially patch the build system not to install backward zones.
Well, there used to be a build option for that in the base system, but somebody just took it out...
Easy enough to put back if someone yells about it.
Paul> Might make sense to put it back in (if only for compatibility Paul> with older FreeBSD systems where TZ='W-SU' gave you UTC :-). But the real point here is that we _want_ some of the backward zones - especially the ones that users may have legitimately configured with tzsetup (which reads zone.tab / zone1970.tab) in the past but which got renamed (as in the recent example of America/Godthab). The problem right now is that there isn't a way to conveniently distinguish those zones from the ones that just get in the way and cause confusion. This is why my proposal retains in the "backward" file every zone that has ever been in zone.tab. -- Andrew.
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
But the real point here is that we _want_ some of the backward zones - especially the ones that users may have legitimately configured with tzsetup (which reads zone.tab / zone1970.tab) in the past but which got renamed (as in the recent example of America/Godthab). The problem right now is that there isn't a way to conveniently distinguish those zones from the ones that just get in the way and cause confusion. This is why my proposal retains in the "backward" file every zone that has ever been in zone.tab.
It's not clear to me whether your proposal includes removal of the newly "deprecated" zones from the default build rule. If it doesn't, then this is just paper-shuffling so far as many (most?) consumers of tzdata are concerned. It gets considerably more real if the proposal is to not include the "deprecated" source file in the standard Makefile build rule. Postgres, for instance, has for some time just used whatever is in the distributed tzdata.zi file. So we'd either continue to support these zones, or not, depending on what happens in the build process for that file. I don't currently have an opinion on whether changing that would be a good or bad thing ... but as far as I could see, you didn't say what you wanted to happen. regards, tom lane
I wrote:
It's not clear to me whether your proposal includes removal of the newly "deprecated" zones from the default build rule.
After further thought I've concluded that I don't like Andrew's proposal as-presented. If some zone names are moved into a new source file, what will inevitably happen is that some platforms/ repackagers will continue to support those names, while others will not --- either through conscious choice or just by forgetting to update their build recipes. That seems like a bad situation to create. Like it or not, tzdb has created a de facto standard for the set of known zone names, and it's better for a standard to be actually standard, not subject to local whims. Recall that in the other thread Andrew referred to, FreeBSD got ragged on for being the only major platform not supporting the "backward" zones. That was justifiable IMO, and I don't think that situation should be reintroduced or magnified. Thus, I think it would be better to either do nothing, or decide that these zone names are dead, and summarily remove them altogether. While the latter option would no doubt cause some pain somewhere, it's not without precedent. I compare it to the effort not so long ago to remove undocumented zone abbreviations. That did result in some push-back, but not a huge amount ... and what's more to the point for the current discussion, downstream packagers were not given any choice in the matter. In short, I don't care hugely whether these zone names live or die; but let's either kill them off everywhere or nowhere. regards, tom lane
On 2020-05-04 21:41, Paul Eggert wrote:
On 5/4/20 8:16 PM, Philip Paeps wrote:
It looks like we install the files rather than links. Or I've botched something on the test machine I looked at (which is not unlikely).
If you're installing files then that should get fixed. In tzdb on my Fedora 31 platform (ext4 filesystem with 4 KiB blocks), 'make install' creates a zoneinfo directory that 'du' reports consumes 1800 KiB, as opposed to the 1776 KiB consumed for the same directory with 'make BACKWARD="" install'. The 24 KiB difference comes mostly from the five extra directories implied by 'backward' (Brazil, Canada, Chile, Mexico, US) each of which consume 4 KiB; the rest comes from the larger tzdata.zi file (108 vs 112 KiB allocated, due to the extra -L lines).
A number of distros seem to end up installing file copies or symbolic rather than hard links under /usr/share/zoneinfo. I created a simple shell script to check GMT link count and if not > 1, `find` all symlinks, relink symbolic as hard links, `find` all files, `sort` by size, `cmp` those of the same size, and hard `link` them if identical, with before and after summary unique and total inode, link, and file counts and sizes. For systems installing right with copies, it drops the size from three copies
4.5MB to two copies ~3.4MB; for systems installing right with symlinks, it only reduces the size of each copy by the size of the symlink paths, about 25KB/copy, but avoids the indirection access.
[I became wary of tz performance, when one process on an AIX system took about 1s per naive `getenv` TZ save, `putenv` TZ set, `tzset` to load data and switch tz in a thread, and it was doing a couple of switches per transaction, depending on front end user locales. Going via the DB interface instead provided caching to speed up lookups, and minor local caching avoided lookups as much as possible.]
Or they can trivially patch the build system not to install backward zones.
Well, there used to be a build option for that in the base system, but somebody just took it out...
Easy enough to put back if someone yells about it.
Might make sense to put it back in (if only for compatibility with older FreeBSD systems where TZ='W-SU' gave you UTC :-).
It would be nice to get some tzdata- alternative packages with -minimal, -tiny, -big, -full, etc. variants depending on build options, perhaps more meaningful names; similar to dict, scowl, words list packages on some distros. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.]
On 2020-05-04, at 21:16:42, Philip Paeps wrote:
On 2020-05-05 11:00:18 (+0800), Andrew Gierth wrote:
Installing "backward" should create only links, and therefore have negligible effect on the size, the only real penalty being the extra directories and entries which should be only a few blocks at most.
It looks like we install the files rather than links. Or I've botched something on the test machine I looked at (which is not unlikely).
It varies. On Linux I see numerous symlinks. (Doesn't a symlink use a disk block?) On MacOS, I see neither symlinks nor multiple directory links, but many duplicate files. -- gil
On 5 May 2020, at 15:27, Paul Gilmartin via tz <tz@iana.org> wrote:
On 2020-05-04, at 21:16:42, Philip Paeps wrote:
On 2020-05-05 11:00:18 (+0800), Andrew Gierth wrote:
Installing "backward" should create only links, and therefore have negligible effect on the size, the only real penalty being the extra directories and entries which should be only a few blocks at most.
It looks like we install the files rather than links. Or I've botched something on the test machine I looked at (which is not unlikely).
It varies.
On Linux I see numerous symlinks. (Doesn't a symlink use a disk block?)
Reasonably short symlinks are stored in the inode. Links, though, are just an entry in a directory so don't occupy any additional space unless you have a few thousand of them. jch
On MacOS, I see neither symlinks nor multiple directory links, but many duplicate files.
Disk space is cheap :) jch
"Paul" == Paul Eggert <eggert@cs.ucla.edu> writes:
Paul> Getting back to the main point, I'm not sure it's worth Paul> deprecating links like 'US/Pacific' any time soon, as so many Paul> people use them Are there any statistics on that? The US/* names are one thing, but what about the nonsense like "W-SU"? The random selection of places that get top-level entries for no readily apparent reason? If there's actual usage justification for keeping US/* specifically in backward, or making it its own compatibility file, I have no particular objection, but it doesn't justify not clearing up the rest of the mess. -- Andrew.
On 5/4/20 8:06 PM, Andrew Gierth wrote:
"Paul" == Paul Eggert <eggert@cs.ucla.edu> writes:
Paul> Getting back to the main point, I'm not sure it's worth Paul> deprecating links like 'US/Pacific' any time soon, as so many Paul> people use them
Are there any statistics on that?
The US/* names are one thing, but what about the nonsense like "W-SU"?
I don't know of any statistics. A quick Google search suggests that TZ='US/Pacific' is far more common than TZ='W-SU'. That being said, I did find a few instances of the latter, including: http://forum.ixbt.com/topic.cgi?id=24:29252 https://github.com/rstudio/bookdown/issues/440 https://postgrespro.ru/list/thread-id/1220710
Paul Eggert <eggert@cs.ucla.edu> wrote on Mon, 4 May 2020 at 20:46:52 EDT in <7949485f-7efc-5590-ac50-a12dfd4c7718@cs.ucla.edu>:
Getting back to the main point, I'm not sure it's worth deprecating links like 'US/Pacific' any time soon, as so many people use them
I would strongly object to such deprecation. I realize we've set ourselves on such a path in a historical decision I disagree with, and that there's a desire not to relitigate it, but those links make a logical sense that should not be ignored. Leave those alone, please. Conservatism cautions against unnecessary churn. -- jhawk@alum.mit.edu John Hawkinson
and their cost is not great. It might be worth coming up with some division of the existing 'backward' file (e.g., recently-backward names vs older-backward names), although I'm not sure what that would look like. I suppose we could have a comment associated with each name saying when it became backward, though that'd increase maintenance hassle.
On 2020-05-04, at 18:26:22, Andrew Gierth wrote:
I mean that where the tzcode uses "GMT" as a default zone name or abbreviation in the absence of data, FreeBSD uses "UTC" (and has since 2004).
e.g. with no /etc/localtime file,
% env -u TZ date Tue 5 May 2020 00:00:37 UTC
(To the best of my knowledge there are no reference clocks available to which one could synchronize in order to use a mean solar time, so your argument seems to me to support this choice.)
Do you mean mean solar time at some arbitrary precise longitude or mean solar time at the Prime Meridian? If the latter, is interpolated UT1 a close enough approximation?: https://www.nist.gov/pml/time-and-frequency-division/time-services/ut1-ntp-t... -- gil
On Mon 2020-05-04T19:58:42-0600 Paul Gilmartin via tz hath writ:
On 2020-05-04, at 18:26:22, Andrew Gierth wrote:
(To the best of my knowledge there are no reference clocks available to which one could synchronize in order to use a mean solar time, so your argument seems to me to support this choice.)
Do you mean mean solar time at some arbitrary precise longitude or mean solar time at the Prime Meridian? If the latter, is interpolated UT1 a close enough approximation?: https://www.nist.gov/pml/time-and-frequency-division/time-services/ut1-ntp-t...
UT1 is not mean solar time, but it is the quantity which is conventionally recognized as mean solar time. In 1954 Sadler recognized that by its existing convention UT (not then yet named UT1) deviates from mean solar time. https://www.ucolick.org/~sla/leapsecs/Sadler1954.pdf Seago and Seidelmann explored this much more deeply in 2013 https://www.agi.com/resources/white-papers/the-mean-solar-time-origin-of-uni... and showed how an alternative formulation might be developed if calendar days are to continue be determined by measuring rotation of the earth. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m
On 2020-05-04 19:58, Paul Gilmartin via tz wrote:
On 2020-05-04, at 18:26:22, Andrew Gierth wrote:
I mean that where the tzcode uses "GMT" as a default zone name or abbreviation in the absence of data, FreeBSD uses "UTC" (and has since 2004). e.g. with no /etc/localtime file, % env -u TZ date Tue 5 May 2020 00:00:37 UTC
(To the best of my knowledge there are no reference clocks available to which one could synchronize in order to use a mean solar time, so your argument seems to me to support this choice.)
Do you mean mean solar time at some arbitrary precise longitude or mean solar time at the Prime Meridian? If the latter, is interpolated UT1 a close enough approximation?: https://www.nist.gov/pml/time-and-frequency-division/time-services/ut1-ntp-t...
No, as the precision of UT1 based on the Earth Rotation Angle is ms a day; UT1R has 62 smoothing terms; UT2 smoothes out seasonal variations; some variation of UT would be required to provide mean solar time at a consistent rate. NIST are still applying radio clock accuracy standards with ~ms precision, where the current norm is ~us from GPS, certainly over local LAN and even over decent remote WAN links. The older standard is adequate for MS products which require only watch-and-eyeball accuracy, but more systems are needing more accurate time. [The point may be moot, as the lawyers heading the US FCC approved the junk science from US Ligado Networks lawyers that say GNSS will not be disrupted by their terrestrial L band transmissions. Those disrupted will have to prove to US FCC lawyers that they were disrupted by US Ligado Networks transmissions. Ligado used to be LightSquared which went bankrupt when their testing proved their transmissions would disrupt GNSS. The FCC no longer requires tests, just sworn assertions from lawyers, if the lawyers approve how the physics is used!] -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.]
On Tue 2020-05-05T13:14:44-0600 Brian Inglis hath writ:
On 2020-05-04 19:58, Paul Gilmartin via tz wrote:
On 2020-05-04, at 18:26:22, Andrew Gierth wrote:
(To the best of my knowledge there are no reference clocks available to which one could synchronize in order to use a mean solar time, so your argument seems to me to support this choice.)
Do you mean mean solar time at some arbitrary precise longitude or mean solar time at the Prime Meridian? If the latter, is interpolated UT1 a close enough approximation?: https://www.nist.gov/pml/time-and-frequency-division/time-services/ut1-ntp-t...
No, as the precision of UT1 based on the Earth Rotation Angle is ms a day; UT1R has 62 smoothing terms; UT2 smoothes out seasonal variations; some variation of UT would be required to provide mean solar time at a consistent rate. NIST are still applying radio clock accuracy standards with ~ms precision, where the current norm is ~us from GPS, certainly over local LAN and even over decent remote WAN links.
The UK radio broadcast time signals stopped providing GMT in 1953. Starting then they transmitted Provisional Uniform Time, PUT, which was their own forerunner version of UT2. The US radio broadcast time signals made similar changes around then. The USNO version of uniform time scale had names like N3c. So since the 1950s there has been no real-time source of mean solar time, only quartz and cesium clock time adjusted to follow that.
The older standard is adequate for MS products which require only watch-and-eyeball accuracy, but more systems are needing more accurate time.
Different sources of radio broadcast time signals did not agree to within 1 ms until 1960 when the US and UK began to coordinate their transmissions using cesium. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m
participants (10)
-
Andrew Gierth -
Brian Inglis -
J William Piggott -
John Hawkinson -
John Haxby -
Paul Eggert -
Paul Gilmartin -
Philip Paeps -
Steve Allen -
Tom Lane