Re: [tz] [Tzdist-bis] [calsify] tzdist and IANA
adding the tz mailing in the discussion Yours, Daniel On Thu, Jul 18, 2019 at 5:41 AM Martin Burnicki < martin.burnicki@burnicki.net> wrote:
Eliot Lear wrote:
On 18 Jul 2019, at 10:29, Martin Burnicki <martin.burnicki@burnicki.net>
wrote:
Hi all,
Eliot Lear wrote:
Hi everyone,
While the IANA does a great job at servicing our assigned number needs and delivering the TZ database to developers, they is not set up, nor
do
they have *any* experience, to handle the load that end clients could place on them. Moreover, they are in no position to support millions of people if something goes wrong. And make no mistake: something will go wrong. I would be okay with a limited tzdist service for those who are going to be distributing the data themselves, but the order of receivers should be on 100s not millions.
Wouldn't it be nice to have an infrastructure similar to what the NTP pool provides for time synchronization?
I guess I would want to see commitment from those who provide TZ service to their customers today to go to such a new service before investing a lot of money. Would Red-hot, Apple, Microsoft, Debian, Ubuntu, or any of the others want to use it? I also realize that ICANN is well positioned to fund this sort of thing, but it is not clear to me that it is right for them to do so. There has to be a real need, and those who really need it perhaps should foot the bill.
I'm working at Meinberg https://www.meinbergglobal.com/
and we are manufacturing NTP/PTP servers, beside related time synchronization stuff.
In the past, whenever governments as of Egypt, Morocco, etc. decided to start or end DST just a couple of days before this really happens we get support requests from industries, telecommunication companies, etc., asking if our time servers could fix the problem to update the TZ data quickly enough.
We always have to tell them they need to wait until a new TZ DB has been released, and then hope that their OS maintainers (Microsoft, Apple, Linux distros, etc.) pick up the new TZ DB version and provide a software/firmware update just to provide the latest changes quickly.
Providing these updates also requires quite some effort for the maintainers, and it would be much easier for them if this kind of information could be updated automatically, which should also be faster than with manual intervention required.
TZ data must not be requested from a server as often as the current time, so I think that even if the data size is larger than an NTP packet the overall load compared to NTP will not be much higher than for a server that provides NTP services, and if I remember correctly then data only needs to be transferred if changes have become available.
So I think this type of service and its advantages just need to be made more public, to let the OS maintainers learn that they have less work with rolling out and deploying software updates if they just use TZDIST.
I'd expect that a TZDIST pool could be operated by volunteers, just like the NTP pool.
Martin
_______________________________________________ Tzdist-bis mailing list Tzdist-bis@ietf.org https://www.ietf.org/mailman/listinfo/tzdist-bis
Daniel Migault wrote on 18/07/2019 15:07:
>> Wouldn't it be nice to have an infrastructure similar to what the NTP >> pool provides for time synchronization?
My two cents of an admin of hosts (mainly Windows) that travel back and forth thru the seven seas (namely Cruise ships). Short version: TZ sync is a pain in the arse. Long version. You cannot use UTC for all the hosts because, for instance, some of them show information to the guests or are used to manage crew shifts (always expressed in ship time). On some ships the so called "master clock" has two NTP servers: one "classic" UTC and the other with ship time. We cannot use ship time NTP server because NTP clients (correctly) assume that NTP is about UTC, while the local time is just a "logical view" of NTP. If we sync Windows hosts with ship time the result is a mess (somebody said "Kerberos"?). We concocted a simple way to sync TZ between Windows hosts. The "TZ Server" runs the command tzutil /g > c:\tz\tz.txt C:\tz is shared as TZ Every client issue the commands set /p TZ=<\\TZSERVER\TZ\TZ.TXT tzutil /s "%TZ%" The procedure is tested on Win2016, 2012R2 and Win10 Detailed info in my blog article: https://translate.google.com/translate?sl=it&tl=en&u=https%3A%2F%2Fsiamogeek... The original is in Italian: https://siamogeek.com/2019/06/sincronizzare-la-time-zone/ -- Ciao, luigi / +--[Luigi Rosa]-- \
On Jul 18, 2019, at 9:27 AM, Luigi Rosa <lists@luigirosa.com> wrote:
[EXTERNAL EMAIL] Daniel Migault wrote on 18/07/2019 15:07:
>> Wouldn't it be nice to have an infrastructure similar to what the NTP >> pool provides for time synchronization?
My two cents of an admin of hosts (mainly Windows) that travel back and forth thru the seven seas (namely Cruise ships).
Short version: TZ sync is a pain in the arse.
Long version. You cannot use UTC for all the hosts because, for instance, some of them show information to the guests or are used to manage crew shifts (always expressed in ship time).
On some ships the so called "master clock" has two NTP servers: one "classic" UTC and the other with ship time.
We cannot use ship time NTP server because NTP clients (correctly) assume that NTP is about UTC, while the local time is just a "logical view" of NTP. If we sync Windows hosts with ship time the result is a mess (somebody said "Kerberos"?).
That seems like the hard way to solve the issue. It seems far more natural just to run NTP the way it was designed, and on any host where you want to show local time, just set its TZ to the value you want and change it when you sail into another timezone. paul
Paul.Koning@dell.com wrote on 18/07/2019 15:35:
That seems like the hard way to solve the issue. It seems far more natural just to run NTP the way it was designed, and on any host where you want to show local time, just set its TZ to the value you want and change it when you sail into another timezone.
That's exactly what that script does: sets the TZ on every host. Automaticcally, not manually. Of couse the scripts are scheduled. -- Ciao, luigi / +--[Luigi Rosa]-- \
On 2019-07-18 15:47:04 (+0200), Luigi Rosa wrote:
Paul.Koning@dell.com wrote on 18/07/2019 15:35:
That seems like the hard way to solve the issue. It seems far more natural just to run NTP the way it was designed, and on any host where you want to show local time, just set its TZ to the value you want and change it when you sail into another timezone.
That's exactly what that script does: sets the TZ on every host. Automaticcally, not manually. Of couse the scripts are scheduled.
Out of genuine interest, not trolling. Are those scripts scheduled on UTC? Or do you schedule them to run at fixed "time since departure" or some such? Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
Philip Paeps wrote on 18/07/2019 18:08:
That's exactly what that script does: sets the TZ on every host. Automaticcally, not manually. Of couse the scripts are scheduled.
Out of genuine interest, not trolling. Are those scripts scheduled on UTC? Or do you schedule them to run at fixed "time since departure" or some such?
The TZ server saves the TZ file every 15 minutes. Unattended Windows hosts (servers and unattended PCs) read TZ info every 15 minutes. Windows 10 clients read TX info at user logon -- Ciao, luigi / +--[Luigi Rosa]-- \
Luigi Rosa wrote:
Daniel Migault wrote on 18/07/2019 15:07:
>> Wouldn't it be nice to have an infrastructure similar to what the NTP >> pool provides for time synchronization?
My two cents of an admin of hosts (mainly Windows) that travel back and forth thru the seven seas (namely Cruise ships).
Short version: TZ sync is a pain in the arse.
Yep.
Long version. You cannot use UTC for all the hosts because, for instance, some of them show information to the guests or are used to manage crew shifts (always expressed in ship time).
On some ships the so called "master clock" has two NTP servers: one "classic" UTC and the other with ship time.
Yep. We had a customer (a cruise line) who received this solution from us. The main problem was that there were dumb date/time displays for the passengers which display whichever time they receive from the NTP server, without applying any offset. So the solution was to install an extra NTP server which provided UTC + a configurable offset for the clocks visible to passengers. And the local time offset to be applied to UTC had to be reconfigured whenever the ship enters a region with a different time zone. Of course this is an evil workaround for limitations of the time displays. Formerly there were clocks that were controlled by an IRIG time code signal which could transport lo time instead of UTC. I'm assuming the folks who developed these dump NTP clocks simply replaced the time code receiver by a network port, without keeping in mind that NTP has been designed to transport UTC only, not local time. For such dump time displays even the tzdist protocol probably won't help much. Only if the displays know about time zones the zone rules could be updated via the network, but still you had to tell each display *which* zone to use if the ship moves from one region to the next.
We cannot use ship time NTP server because NTP clients (correctly) assume that NTP is about UTC, while the local time is just a "logical view" of NTP. If we sync Windows hosts with ship time the result is a mess (somebody said "Kerberos"?).
Of course.
We concocted a simple way to sync TZ between Windows hosts.
The "TZ Server" runs the command
tzutil /g > c:\tz\tz.txt
C:\tz is shared as TZ
Every client issue the commands
set /p TZ=<\\TZSERVER\TZ\TZ.TXT tzutil /s "%TZ%"
The procedure is tested on Win2016, 2012R2 and Win10
Detailed info in my blog article: https://translate.google.com/translate?sl=it&tl=en&u=https%3A%2F%2Fsiamogeek...
The original is in Italian: https://siamogeek.com/2019/06/sincronizzare-la-time-zone/
Thanks for these interesting pointers. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
Martin Burnicki wrote on 18/07/2019 16:05:
For such dump time displays even the tzdist protocol probably won't help much. Only if the displays know about time zones the zone rules could be updated via the network, but still you had to tell each display *which* zone to use if the ship moves from one region to the next. For vessel operations there is no reliable method other than heaving the IT Officer (or the equivalent) set the Time Zone in a "master server" that distributes the TZ settings.
-- Ciao, luigi / +--[Luigi Rosa]-- \
AFAIK, tzdist isn't about setting the active time zone across computers. It's about making sure those computers have reliable time zone data. In Windows, tzutil.exe can list the time zones available, and can set the active time zone. There are also other ways to set the active time zone across computers. For example, if they are in a domain you can use group policy to update registry settings. You could also use Set-TimeZone in powershell. See: https://dennisspan.com/configuring-the-time-zone-and-code-page-with-group-po... In Windows, time zone data updates (including Microsoft and IANA time zone data) are handled through Windows Update. On Linux, IANA data is typically pushed out via a "tzdata" package. The benefit of a tzdist-like system would simply be that time zone updates could be pushed out more rapidly than these other update processes typically take. In other words, it is simply an out-of-band, purpose-built update process. Such a process would be helpful when governments do not allow enough lead time for updates to get created and distributed, such as described in my blog post: https://codeofmatt.com/on-the-timing-of-time-zone-changes<https://codeofmatt.com/on-the-timing-of-time-zone-changes/> -Matt ________________________________ From: tz <tz-bounces@iana.org> on behalf of Luigi Rosa <lists@luigirosa.com> Sent: Thursday, July 18, 2019 6:27 AM To: tz@iana.org <tz@iana.org> Subject: Re: [tz] [Tzdist-bis] [calsify] tzdist and IANA Daniel Migault wrote on 18/07/2019 15:07:
>> Wouldn't it be nice to have an infrastructure similar to what the NTP >> pool provides for time synchronization?
My two cents of an admin of hosts (mainly Windows) that travel back and forth thru the seven seas (namely Cruise ships). Short version: TZ sync is a pain in the arse. Long version. You cannot use UTC for all the hosts because, for instance, some of them show information to the guests or are used to manage crew shifts (always expressed in ship time). On some ships the so called "master clock" has two NTP servers: one "classic" UTC and the other with ship time. We cannot use ship time NTP server because NTP clients (correctly) assume that NTP is about UTC, while the local time is just a "logical view" of NTP. If we sync Windows hosts with ship time the result is a mess (somebody said "Kerberos"?). We concocted a simple way to sync TZ between Windows hosts. The "TZ Server" runs the command tzutil /g > c:\tz\tz.txt C:\tz is shared as TZ Every client issue the commands set /p TZ=<<file://>\\TZSERVER\TZ\TZ.TXT tzutil /s "%TZ%" The procedure is tested on Win2016, 2012R2 and Win10 Detailed info in my blog article: https://translate.google.com/translate?sl=it&tl=en&u=https%3A%2F%2Fsiamogeek... The original is in Italian: https://siamogeek.com/2019/06/sincronizzare-la-time-zone/ -- Ciao, luigi / +--[Luigi Rosa]-- \
Early in this thread it was mentioned the the time zone database should be served in a fashion similar to DNS. My first thought was the numbers are wildly different. I jotted down a first cut at identifying the relevant operational parameters. Perhaps the people proposing this service can flesh out the quantitative aspects. Thanks, Steve
Steve Crocker <steve@shinkuro.com> wrote:
Early in this thread it was mentioned the the time zone database should be served in a fashion similar to DNS.
We could just use the DNS :-) As Paul pointed out, TZif files are not very big. I have experimentally shoved the zoneinfo files from my workstation into a DNS zone I happen to have lying around. I've deflated (RFC 1950) each file (RFC 8536) and picked an arbitrary RR type 29818 = 0x747A = 'tz'. The result appears below as a hex blob (RFC 3597) which does not quite fit in the Ethernet MTU, but you can get the answer over UDP if you allow EDNS with fragmentation. It's signed with DNSSEC so you can be sure I am to blame. https://pbs.twimg.com/media/DY5rHo_WAAEISGh.jpg ; <<>> DiG 9.15.1 <<>> +dnssec +multiline London.Europe.tz.dotat.at. TYPE29818 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32632 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1420 ; COOKIE: 30e31bd663d426f6eb79a79f5d307ef6114d7eabab9d3c0e (good) ;; QUESTION SECTION: ;London.Europe.tz.dotat.at. IN TYPE29818 ;; ANSWER SECTION: London.Europe.tz.dotat.at. 3412 IN CNAME GB.tz.dotat.at. London.Europe.tz.dotat.at. 3412 IN RRSIG CNAME 5 5 3600 ( 20190728110326 20190718100326 56700 dotat.at. R7ynL3bJ7uScgbF3GNSKzuXZZZKnTF6ZKObqh9y5LIwI voZSo46m1jv6HwkQBUDvmMSYzSfW0TDqzxz6BDrxb+VG aBITB2DyJeI6OXcJYQXbyGpqP9Brc7k5B6js1oyFOMru hLDqOxSlZTIW3pimnV17LQqI7ve/FPygHN26+rE= ) GB.tz.dotat.at. 3412 IN TYPE29818 \# 1751 ( 789CEDD67B74CF751CC7F1DF9A61CBE5438CCCE5A3B9 34CDFC36914B4BEE8D6DB9FCD22FD208439666691969 3995E238CE5B472DA13E2296582E5B2E4BAE0DD19026 26B985CDFD9A319B3ECF2F754EC7395DFFEDF73BDBE3 B7DF3867E7ECECFD7C79FA0E8F8F70DDF1287FFB83C7 A5DBAFABBC663FCD6CB4D8CCDCE3A767ED709BD9F336 9A0F67CD361FA5D532E6CDD57A4EF20DF3F190597AEE B82D665EEC4AF349BB623DBFE100BDA0718E4E6F12AA D34F159985AEDD66615E75FD59E179BD6873825EBCF5 3B9DB120567F6E52CC92B7DC7AE93B3BCDB2C468B33C 6999C9EC1166B2A2FAEA2FDCCAAC8848362B2B5F34AB AA7ACDAA73DF9BD5852E9DBDF782FE72FF937ACDCADD FAABA5A566EDFB597ADDCC20BD7E4C9ADE30B6446FF4 A6E84D3DE799AF5BF5D3396DD6EBCDDE3D6673BEBFF9 26B0917C93F6946CDB5557B6BFDC56BE5DEA92DC015E B5438EC8CE91CFC8AEA440B5AB38427D37BC54EF1E14 62BE8F3AA4F3EAD637791D4A24EFE021B5277691DE53 EA6BF6864DD57BAFBDABF32B25EAFC53A7F5FE6335CC 8FDB72F5814DD7CC4F9927CDC18C407D68FA767338E9 317364C4687DB45713F3B347CCB1880AE678E4627D22 28441754F39882E2BB7561C9287D32FF8C3E75A0B73E BD7A873EB3FCBA39FBC1527D6EC25073FEA3F1FAC2C0 287331354E5FEA16AF2FC7B5D757EA5734BFB40BD657 5DE74C513D3F5D746897B9567A425F5FB7DC1417F89A 1BE33E33259BB3137D1373749910AFF6EB91AECBFAB7 D1E5DC9375B9C2DADA5F2568FF2DA53AE07CACBE7B59 2D5361A75B579C76C3545A5255571EF5935133C24C95 9EEB4CD51465EE09FFD854F35E34D5834F4960AB1CA9 E1FBADD4AC992E358F7E2EF7164D965A1BA749D0E105 AAF6A20C5567FD2455778AA87A7346289D90A4EA4F88 51F7457B54F0C066AA41684BD5B05B776954A1A66ADC A4A934BEF2A08404549690BC40695278411EC82C92D0 ADBBA5E9F47C09FB344B9A8DFE52DC93D2C47DA2812B BCFF3E159194A99A4766AB077BBDA75AD499AD5A468C 512D4B5255ABA0E9D2EAC040D5BA3859DAACE9A8DAEE F7CAC3F3E32432BB8D3C32B1BDB49B595B1E8D0F96F6 6FB4561DBAF849C7C141AA53C313D2B96389EAE2B755 BA061F545DCF1E5751BEEB5554EE16D5EDE85CD53D63 A18ADEBE5662A64E51B18BE6C8E32347AA1E535E979E 4F4E965E0943A4F74309E289EE2A4FD488953EA121D2 E7AA5BBCD5BB28EF0F55E5A92BF7ABBE5F5C967E7901 EA695345F5CF3CAD9E49BDA4E2A6E7AA0171796AE0F8 93F26CBB156A50FFED32B8DE0C35243243E2CB67C9D0 3A22430BD2645849920CDF9222CF1DF0C888F47E9290 334A3DFF76A48C9CDF5BBD30AC9E244E6CA146F57C58 25C5D7502F86D755A33B5F532F5571A9E466D525F9FC 1135A6D25519B373934A39BB4FC62E99AFC6E566CB2B 3336C8F88CD9F26ACA3C499D9A2A77F9FCD3A7EFEFCF 5B5FFDFDFF59A6EC9D6FFA95FDB367B93FFFF6BF7BDE BC79338B7B5649F994F9EDC8D5D63E1578C755E68FEF F3393AC6E3EAD0DBE3EA8A9DEC0B978F8F8FFDB87515 AD9EBFBE9D977FBB9D45B7DFB03FC4CD5AFDFDB721B7 D4D1DE53E4A6227715B9ADC87D456E2C7267915B8BDC 5BE4E6227717B9BDC8FD456EB0A3BDC3C82D76B4F718 B9C9C85D466E33729F911B8DDC69E45623F71AB9D9C8 DD466E3772BF911B8EDC71E4963BDA7B8EDC74E4AE23 B71DB9EFC88D47EE3C72EB917B8FDC7CE4EE23B71FB9 FF4803900E38DA16203D70B44D40BA80B401E903D208 A413482B905E38DA6620DD40DA81F4036988A3ED88A3 6D09D21347DB14A42B8EB62D485F1C6D6390CE20AD41 7A833407E90ED21EA43F4883900E212D427A843409E9 12D22647DB27A45148A7905621BD429A85740B6917D2 2FA46148C79096213D439A86740D691BD23747DB38A4 7348EB90DE21CD43BAC7DF1AED43FA873410E920D242 47DB43A4898EB68B481B913E228D443AE91C12DB4AA4 974833916E22ED44FA893414E928D252A4A748531D6D 5791B6227D451A8B7416692DD25BA4B9487791F622FD 451A8C74186931D263A4C98EB6CB489B1D6D9F914623 9D465A8DF41A6936D26DA4DD8EB6DF3C6838D271A4E5 48CF91A6235D77B46D47FAEE681B8F741E693DD27BA4 F948F791F623FD473600B203902D80EC01641320BB00 D906C83E70B41B01D9098E762B207B01D90CC86E40B6 03B21F900D81EC08644B207B02D914C8AE40B605B22F 1CEDC6407686A3DD1AC8DE403607B23B90ED81EC0F64 83203B04D922C81E413609B24B906D82EC1364A3203B C5B1E0D6EF97BD826C1664B720DB05D92FC88641760C B265903D836C1A64D720DB06D937C8C641768EA3DD3A C8DE71B49B07D93DC8F641F60FB281901D846C21640F B9FE1F44FF7D1005D8EFB8EDBF088D691ED622CCDD2C 3C3426DCCDAB805F0162E35BFB ) GB.tz.dotat.at. 3412 IN RRSIG TYPE29818 5 4 3600 ( 20190728110326 20190718100326 56700 dotat.at. JMbEh9MzMHhSIuLF+capNcNEkoa5Q2McgQSBpjS84w4v ROpglw84OgCYunhmI5xmxVgqCUHd4+romQK86xvfit9j 4Gs2kHTKOEjcxfvVbxLoUGkjZOe6zBeaT2tXRx/gQnUq +md2j8+NKEbcRi8oL4YdDjdMsmFo5SntpbRd19E= ) ;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Thu Jul 18 15:15:18 BST 2019 ;; MSG SIZE rcvd: 2209 Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Fair Isle, East Faeroes: Mainly southerly 4 or 5, increasing 6 at times. Moderate, occasionally slight. Occasional rain or showers. Moderate or good, occasionally poor.
On 7/18/19 10:32, Tony Finch wrote:
Steve Crocker <steve@shinkuro.com> wrote:
Early in this thread it was mentioned the the time zone database should be served in a fashion similar to DNS. We could just use the DNS :-) As Paul pointed out, TZif files are not very big.
DNS keeps turning up as a suggestion. However, just because tz distribution has some vague similarity to DNS doesn't make it a good idea. I'm sure it can be done but a simple RESTful interface over https is simpel and easily implemented.
I have experimentally shoved the zoneinfo files from my workstation into a DNS zone I happen to have lying around. I've deflated (RFC 1950) each file (RFC 8536) and picked an arbitrary RR type 29818 = 0x747A = 'tz'. The result appears below as a hex blob (RFC 3597) which does not quite fit in the Ethernet MTU, but you can get the answer over UDP if you allow EDNS with fragmentation. It's signed with DNSSEC so you can be sure I am to blame. https://pbs.twimg.com/media/DY5rHo_WAAEISGh.jpg
; <<>> DiG 9.15.1 <<>> +dnssec +multiline London.Europe.tz.dotat.at. TYPE29818 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32632 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1420 ; COOKIE: 30e31bd663d426f6eb79a79f5d307ef6114d7eabab9d3c0e (good) ;; QUESTION SECTION: ;London.Europe.tz.dotat.at. IN TYPE29818
;; ANSWER SECTION: London.Europe.tz.dotat.at. 3412 IN CNAME GB.tz.dotat.at. London.Europe.tz.dotat.at. 3412 IN RRSIG CNAME 5 5 3600 ( 20190728110326 20190718100326 56700 dotat.at. R7ynL3bJ7uScgbF3GNSKzuXZZZKnTF6ZKObqh9y5LIwI voZSo46m1jv6HwkQBUDvmMSYzSfW0TDqzxz6BDrxb+VG aBITB2DyJeI6OXcJYQXbyGpqP9Brc7k5B6js1oyFOMru hLDqOxSlZTIW3pimnV17LQqI7ve/FPygHN26+rE= ) GB.tz.dotat.at. 3412 IN TYPE29818 \# 1751 ( 789CEDD67B74CF751CC7F1DF9A61CBE5438CCCE5A3B9 34CDFC36914B4BEE8D6DB9FCD22FD208439666691969 3995E238CE5B472DA13E2296582E5B2E4BAE0DD19026 26B985CDFD9A319B3ECF2F754EC7395DFFEDF73BDBE3 B7DF3867E7ECECFD7C79FA0E8F8F70DDF1287FFB83C7 A5DBAFABBC663FCD6CB4D8CCDCE3A767ED709BD9F336 9A0F67CD361FA5D532E6CDD57A4EF20DF3F190597AEE B82D665EEC4AF349BB623DBFE100BDA0718E4E6F12AA D34F159985AEDD66615E75FD59E179BD6873825EBCF5 3B9DB120567F6E52CC92B7DC7AE93B3BCDB2C468B33C 6999C9EC1166B2A2FAEA2FDCCAAC8848362B2B5F34AB AA7ACDAA73DF9BD5852E9DBDF782FE72FF937ACDCADD FAABA5A566EDFB597ADDCC20BD7E4C9ADE30B6446FF4 A6E84D3DE799AF5BF5D3396DD6EBCDDE3D6673BEBFF9 26B0917C93F6946CDB5557B6BFDC56BE5DEA92DC015E B5438EC8CE91CFC8AEA440B5AB38427D37BC54EF1E14 62BE8F3AA4F3EAD637791D4A24EFE021B5277691DE53 EA6BF6864DD57BAFBDABF32B25EAFC53A7F5FE6335CC 8FDB72F5814DD7CC4F9927CDC18C407D68FA767338E9 317364C4687DB45713F3B347CCB1880AE678E4627D22 28441754F39882E2BB7561C9287D32FF8C3E75A0B73E BD7A873EB3FCBA39FBC1527D6EC25073FEA3F1FAC2C0 287331354E5FEA16AF2FC7B5D757EA5734BFB40BD657 5DE74C513D3F5D746897B9567A425F5FB7DC1417F89A 1BE33E33259BB3137D1373749910AFF6EB91AECBFAB7 D1E5DC9375B9C2DADA5F2568FF2DA53AE07CACBE7B59 2D5361A75B579C76C3545A5255571EF5935133C24C95 9EEB4CD51465EE09FFD854F35E34D5834F4960AB1CA9 E1FBADD4AC992E358F7E2EF7164D965A1BA749D0E105 AAF6A20C5567FD2455778AA87A7346289D90A4EA4F88 51F7457B54F0C066AA41684BD5B05B776954A1A66ADC A4A934BEF2A08404549690BC40695278411EC82C92D0 ADBBA5E9F47C09FB344B9A8DFE52DC93D2C47DA2812B BCFF3E159194A99A4766AB077BBDA75AD499AD5A468C 512D4B5255ABA0E9D2EAC040D5BA3859DAACE9A8DAEE F7CAC3F3E32432BB8D3C32B1BDB49B595B1E8D0F96F6 6FB4561DBAF849C7C141AA53C313D2B96389EAE2B755 BA061F545DCF1E5751BEEB5554EE16D5EDE85CD53D63 A18ADEBE5662A64E51B18BE6C8E32347AA1E535E979E 4F4E965E0943A4F74309E289EE2A4FD488953EA121D2 E7AA5BBCD5BB28EF0F55E5A92BF7ABBE5F5C967E7901 EA695345F5CF3CAD9E49BDA4E2A6E7AA0171796AE0F8 93F26CBB156A50FFED32B8DE0C35243243E2CB67C9D0 3A22430BD2645849920CDF9222CF1DF0C888F47E9290 334A3DFF76A48C9CDF5BBD30AC9E244E6CA146F57C58 25C5D7502F86D755A33B5F532F5571A9E466D525F9FC 1135A6D25519B373934A39BB4FC62E99AFC6E566CB2B 3336C8F88CD9F26ACA3C499D9A2A77F9FCD3A7EFEFCF 5B5FFDFDFF59A6EC9D6FFA95FDB367B93FFFF6BF7BDE BC79338B7B5649F994F9EDC8D5D63E1578C755E68FEF F3393AC6E3EAD0DBE3EA8A9DEC0B978F8F8FFDB87515 AD9EBFBE9D977FBB9D45B7DFB03FC4CD5AFDFDB721B7 D4D1DE53E4A6227715B9ADC87D456E2C7267915B8BDC 5BE4E6227717B9BDC8FD456EB0A3BDC3C82D76B4F718 B9C9C85D466E33729F911B8DDC69E45623F71AB9D9C8 DD466E3772BF911B8EDC71E4963BDA7B8EDC74E4AE23 B71DB9EFC88D47EE3C72EB917B8FDC7CE4EE23B71FB9 FF4803900E38DA16203D70B44D40BA80B401E903D208 A413482B905E38DA6620DD40DA81F4036988A3ED88A3 6D09D21347DB14A42B8EB62D485F1C6D6390CE20AD41 7A833407E90ED21EA43F4883900E212D427A843409E9 12D22647DB27A45148A7905621BD429A85740B6917D2 2FA46148C79096213D439A86740D691BD23747DB38A4 7348EB90DE21CD43BAC7DF1AED43FA873410E920D242 47DB43A4898EB68B481B913E228D443AE91C12DB4AA4 974833916E22ED44FA893414E928D252A4A748531D6D 5791B6227D451A8B7416692DD25BA4B9487791F622FD 451A8C74186931D263A4C98EB6CB489B1D6D9F914623 9D465A8DF41A6936D26DA4DD8EB6DF3C6838D271A4E5 48CF91A6235D77B46D47FAEE681B8F741E693DD27BA4 F948F791F623FD473600B203902D80EC01641320BB00 D906C83E70B41B01D9098E762B207B01D90CC86E40B6 03B21F900D81EC08644B207B02D914C8AE40B605B22F 1CEDC6407686A3DD1AC8DE403607B23B90ED81EC0F64 83203B04D922C81E413609B24B906D82EC1364A3203B C5B1E0D6EF97BD826C1664B720DB05D92FC88641760C B265903D836C1A64D720DB06D937C8C641768EA3DD3A C8DE71B49B07D93DC8F641F60FB281901D846C21640F B9FE1F44FF7D1005D8EFB8EDBF088D691ED622CCDD2C 3C3426DCCDAB805F0162E35BFB ) GB.tz.dotat.at. 3412 IN RRSIG TYPE29818 5 4 3600 ( 20190728110326 20190718100326 56700 dotat.at. JMbEh9MzMHhSIuLF+capNcNEkoa5Q2McgQSBpjS84w4v ROpglw84OgCYunhmI5xmxVgqCUHd4+romQK86xvfit9j 4Gs2kHTKOEjcxfvVbxLoUGkjZOe6zBeaT2tXRx/gQnUq +md2j8+NKEbcRi8oL4YdDjdMsmFo5SntpbRd19E= )
;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Thu Jul 18 15:15:18 BST 2019 ;; MSG SIZE rcvd: 2209
Tony.
We already have a REST-like standard defined for carrying TZ data - RFC 7808. It also appears based upon previous discussions that very few, if any real world implementations and deployments which exist. Perhaps this is because of the complexity of the standard, and maybe defining a simpler subset might be more appealing for implementations. Regards On 18/07/2019 16:52, Michael Douglass wrote:
On 7/18/19 10:32, Tony Finch wrote:
Steve Crocker <steve@shinkuro.com> wrote:
Early in this thread it was mentioned the the time zone database should be served in a fashion similar to DNS. We could just use the DNS :-) As Paul pointed out, TZif files are not very big.
DNS keeps turning up as a suggestion. However, just because tz distribution has some vague similarity to DNS doesn't make it a good idea.
I'm sure it can be done but a simple RESTful interface over https is simpel and easily implemented.
I have experimentally shoved the zoneinfo files from my workstation into a DNS zone I happen to have lying around. I've deflated (RFC 1950) each file (RFC 8536) and picked an arbitrary RR type 29818 = 0x747A = 'tz'. The result appears below as a hex blob (RFC 3597) which does not quite fit in the Ethernet MTU, but you can get the answer over UDP if you allow EDNS with fragmentation. It's signed with DNSSEC so you can be sure I am to blame. https://pbs.twimg.com/media/DY5rHo_WAAEISGh.jpg
; <<>> DiG 9.15.1 <<>> +dnssec +multiline London.Europe.tz.dotat.at. TYPE29818 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32632 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1420 ; COOKIE: 30e31bd663d426f6eb79a79f5d307ef6114d7eabab9d3c0e (good) ;; QUESTION SECTION: ;London.Europe.tz.dotat.at. IN TYPE29818
;; ANSWER SECTION: London.Europe.tz.dotat.at. 3412 IN CNAME GB.tz.dotat.at. London.Europe.tz.dotat.at. 3412 IN RRSIG CNAME 5 5 3600 ( 20190728110326 20190718100326 56700 dotat.at.
R7ynL3bJ7uScgbF3GNSKzuXZZZKnTF6ZKObqh9y5LIwI
voZSo46m1jv6HwkQBUDvmMSYzSfW0TDqzxz6BDrxb+VG
aBITB2DyJeI6OXcJYQXbyGpqP9Brc7k5B6js1oyFOMru
hLDqOxSlZTIW3pimnV17LQqI7ve/FPygHN26+rE= ) GB.tz.dotat.at. 3412 IN TYPE29818 \# 1751 ( 789CEDD67B74CF751CC7F1DF9A61CBE5438CCCE5A3B9
34CDFC36914B4BEE8D6DB9FCD22FD208439666691969
3995E238CE5B472DA13E2296582E5B2E4BAE0DD19026
26B985CDFD9A319B3ECF2F754EC7395DFFEDF73BDBE3
B7DF3867E7ECECFD7C79FA0E8F8F70DDF1287FFB83C7
A5DBAFABBC663FCD6CB4D8CCDCE3A767ED709BD9F336
9A0F67CD361FA5D532E6CDD57A4EF20DF3F190597AEE
B82D665EEC4AF349BB623DBFE100BDA0718E4E6F12AA
D34F159985AEDD66615E75FD59E179BD6873825EBCF5
3B9DB120567F6E52CC92B7DC7AE93B3BCDB2C468B33C
6999C9EC1166B2A2FAEA2FDCCAAC8848362B2B5F34AB
AA7ACDAA73DF9BD5852E9DBDF782FE72FF937ACDCADD
FAABA5A566EDFB597ADDCC20BD7E4C9ADE30B6446FF4
A6E84D3DE799AF5BF5D3396DD6EBCDDE3D6673BEBFF9
26B0917C93F6946CDB5557B6BFDC56BE5DEA92DC015E
B5438EC8CE91CFC8AEA440B5AB38427D37BC54EF1E14
62BE8F3AA4F3EAD637791D4A24EFE021B5277691DE53
EA6BF6864DD57BAFBDABF32B25EAFC53A7F5FE6335CC
8FDB72F5814DD7CC4F9927CDC18C407D68FA767338E9
317364C4687DB45713F3B347CCB1880AE678E4627D22
28441754F39882E2BB7561C9287D32FF8C3E75A0B73E
BD7A873EB3FCBA39FBC1527D6EC25073FEA3F1FAC2C0
287331354E5FEA16AF2FC7B5D757EA5734BFB40BD657
5DE74C513D3F5D746897B9567A425F5FB7DC1417F89A
1BE33E33259BB3137D1373749910AFF6EB91AECBFAB7
D1E5DC9375B9C2DADA5F2568FF2DA53AE07CACBE7B59
2D5361A75B579C76C3545A5255571EF5935133C24C95
9EEB4CD51465EE09FFD854F35E34D5834F4960AB1CA9
E1FBADD4AC992E358F7E2EF7164D965A1BA749D0E105
AAF6A20C5567FD2455778AA87A7346289D90A4EA4F88
51F7457B54F0C066AA41684BD5B05B776954A1A66ADC
A4A934BEF2A08404549690BC40695278411EC82C92D0
ADBBA5E9F47C09FB344B9A8DFE52DC93D2C47DA2812B
BCFF3E159194A99A4766AB077BBDA75AD499AD5A468C
512D4B5255ABA0E9D2EAC040D5BA3859DAACE9A8DAEE
F7CAC3F3E32432BB8D3C32B1BDB49B595B1E8D0F96F6
6FB4561DBAF849C7C141AA53C313D2B96389EAE2B755
BA061F545DCF1E5751BEEB5554EE16D5EDE85CD53D63
A18ADEBE5662A64E51B18BE6C8E32347AA1E535E979E
4F4E965E0943A4F74309E289EE2A4FD488953EA121D2
E7AA5BBCD5BB28EF0F55E5A92BF7ABBE5F5C967E7901
EA695345F5CF3CAD9E49BDA4E2A6E7AA0171796AE0F8
93F26CBB156A50FFED32B8DE0C35243243E2CB67C9D0
3A22430BD2645849920CDF9222CF1DF0C888F47E9290
334A3DFF76A48C9CDF5BBD30AC9E244E6CA146F57C58
25C5D7502F86D755A33B5F532F5571A9E466D525F9FC
1135A6D25519B373934A39BB4FC62E99AFC6E566CB2B
3336C8F88CD9F26ACA3C499D9A2A77F9FCD3A7EFEFCF
5B5FFDFDFF59A6EC9D6FFA95FDB367B93FFFF6BF7BDE
BC79338B7B5649F994F9EDC8D5D63E1578C755E68FEF
F3393AC6E3EAD0DBE3EA8A9DEC0B978F8F8FFDB87515
AD9EBFBE9D977FBB9D45B7DFB03FC4CD5AFDFDB721B7
D4D1DE53E4A6227715B9ADC87D456E2C7267915B8BDC
5BE4E6227717B9BDC8FD456EB0A3BDC3C82D76B4F718
B9C9C85D466E33729F911B8DDC69E45623F71AB9D9C8
DD466E3772BF911B8EDC71E4963BDA7B8EDC74E4AE23
B71DB9EFC88D47EE3C72EB917B8FDC7CE4EE23B71FB9
FF4803900E38DA16203D70B44D40BA80B401E903D208
A413482B905E38DA6620DD40DA81F4036988A3ED88A3
6D09D21347DB14A42B8EB62D485F1C6D6390CE20AD41
7A833407E90ED21EA43F4883900E212D427A843409E9
12D22647DB27A45148A7905621BD429A85740B6917D2
2FA46148C79096213D439A86740D691BD23747DB38A4
7348EB90DE21CD43BAC7DF1AED43FA873410E920D242
47DB43A4898EB68B481B913E228D443AE91C12DB4AA4
974833916E22ED44FA893414E928D252A4A748531D6D
5791B6227D451A8B7416692DD25BA4B9487791F622FD
451A8C74186931D263A4C98EB6CB489B1D6D9F914623
9D465A8DF41A6936D26DA4DD8EB6DF3C6838D271A4E5
48CF91A6235D77B46D47FAEE681B8F741E693DD27BA4
F948F791F623FD473600B203902D80EC01641320BB00
D906C83E70B41B01D9098E762B207B01D90CC86E40B6
03B21F900D81EC08644B207B02D914C8AE40B605B22F
1CEDC6407686A3DD1AC8DE403607B23B90ED81EC0F64
83203B04D922C81E413609B24B906D82EC1364A3203B
C5B1E0D6EF97BD826C1664B720DB05D92FC88641760C
B265903D836C1A64D720DB06D937C8C641768EA3DD3A
C8DE71B49B07D93DC8F641F60FB281901D846C21640F
B9FE1F44FF7D1005D8EFB8EDBF088D691ED622CCDD2C 3C3426DCCDAB805F0162E35BFB ) GB.tz.dotat.at. 3412 IN RRSIG TYPE29818 5 4 3600 ( 20190728110326 20190718100326 56700 dotat.at.
JMbEh9MzMHhSIuLF+capNcNEkoa5Q2McgQSBpjS84w4v
ROpglw84OgCYunhmI5xmxVgqCUHd4+romQK86xvfit9j
4Gs2kHTKOEjcxfvVbxLoUGkjZOe6zBeaT2tXRx/gQnUq
+md2j8+NKEbcRi8oL4YdDjdMsmFo5SntpbRd19E= )
;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Thu Jul 18 15:15:18 BST 2019 ;; MSG SIZE rcvd: 2209
Tony.
On 7/18/19 12:12, Thomas Peterson wrote:
We already have a REST-like standard defined for carrying TZ data - RFC 7808. I know - I'm one of the authors It also appears based upon previous discussions that very few, if any real world implementations and deployments which exist. Perhaps this is because of the complexity of the standard, and maybe defining a simpler subset might be more appealing for implementations.
I can assure you it's very simple to implement. There are at least 3 implementations. The major issue as far as I can tell is getting some organization(s) to agree to host a root service we can build out from. Without that it's going nowhere.
Regards
On 18/07/2019 16:52, Michael Douglass wrote:
On 7/18/19 10:32, Tony Finch wrote:
Steve Crocker <steve@shinkuro.com> wrote:
Early in this thread it was mentioned the the time zone database should be served in a fashion similar to DNS. We could just use the DNS :-) As Paul pointed out, TZif files are not very big.
DNS keeps turning up as a suggestion. However, just because tz distribution has some vague similarity to DNS doesn't make it a good idea.
I'm sure it can be done but a simple RESTful interface over https is simpel and easily implemented.
I have experimentally shoved the zoneinfo files from my workstation into a DNS zone I happen to have lying around. I've deflated (RFC 1950) each file (RFC 8536) and picked an arbitrary RR type 29818 = 0x747A = 'tz'. The result appears below as a hex blob (RFC 3597) which does not quite fit in the Ethernet MTU, but you can get the answer over UDP if you allow EDNS with fragmentation. It's signed with DNSSEC so you can be sure I am to blame. https://pbs.twimg.com/media/DY5rHo_WAAEISGh.jpg
; <<>> DiG 9.15.1 <<>> +dnssec +multiline London.Europe.tz.dotat.at. TYPE29818 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32632 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1420 ; COOKIE: 30e31bd663d426f6eb79a79f5d307ef6114d7eabab9d3c0e (good) ;; QUESTION SECTION: ;London.Europe.tz.dotat.at. IN TYPE29818
;; ANSWER SECTION: London.Europe.tz.dotat.at. 3412 IN CNAME GB.tz.dotat.at. London.Europe.tz.dotat.at. 3412 IN RRSIG CNAME 5 5 3600 ( 20190728110326 20190718100326 56700 dotat.at. R7ynL3bJ7uScgbF3GNSKzuXZZZKnTF6ZKObqh9y5LIwI voZSo46m1jv6HwkQBUDvmMSYzSfW0TDqzxz6BDrxb+VG aBITB2DyJeI6OXcJYQXbyGpqP9Brc7k5B6js1oyFOMru hLDqOxSlZTIW3pimnV17LQqI7ve/FPygHN26+rE= ) GB.tz.dotat.at. 3412 IN TYPE29818 \# 1751 ( 789CEDD67B74CF751CC7F1DF9A61CBE5438CCCE5A3B9 34CDFC36914B4BEE8D6DB9FCD22FD208439666691969 3995E238CE5B472DA13E2296582E5B2E4BAE0DD19026 26B985CDFD9A319B3ECF2F754EC7395DFFEDF73BDBE3 B7DF3867E7ECECFD7C79FA0E8F8F70DDF1287FFB83C7 A5DBAFABBC663FCD6CB4D8CCDCE3A767ED709BD9F336 9A0F67CD361FA5D532E6CDD57A4EF20DF3F190597AEE B82D665EEC4AF349BB623DBFE100BDA0718E4E6F12AA D34F159985AEDD66615E75FD59E179BD6873825EBCF5 3B9DB120567F6E52CC92B7DC7AE93B3BCDB2C468B33C 6999C9EC1166B2A2FAEA2FDCCAAC8848362B2B5F34AB AA7ACDAA73DF9BD5852E9DBDF782FE72FF937ACDCADD FAABA5A566EDFB597ADDCC20BD7E4C9ADE30B6446FF4 A6E84D3DE799AF5BF5D3396DD6EBCDDE3D6673BEBFF9 26B0917C93F6946CDB5557B6BFDC56BE5DEA92DC015E B5438EC8CE91CFC8AEA440B5AB38427D37BC54EF1E14 62BE8F3AA4F3EAD637791D4A24EFE021B5277691DE53 EA6BF6864DD57BAFBDABF32B25EAFC53A7F5FE6335CC 8FDB72F5814DD7CC4F9927CDC18C407D68FA767338E9 317364C4687DB45713F3B347CCB1880AE678E4627D22 28441754F39882E2BB7561C9287D32FF8C3E75A0B73E BD7A873EB3FCBA39FBC1527D6EC25073FEA3F1FAC2C0 287331354E5FEA16AF2FC7B5D757EA5734BFB40BD657 5DE74C513D3F5D746897B9567A425F5FB7DC1417F89A 1BE33E33259BB3137D1373749910AFF6EB91AECBFAB7 D1E5DC9375B9C2DADA5F2568FF2DA53AE07CACBE7B59 2D5361A75B579C76C3545A5255571EF5935133C24C95 9EEB4CD51465EE09FFD854F35E34D5834F4960AB1CA9 E1FBADD4AC992E358F7E2EF7164D965A1BA749D0E105 AAF6A20C5567FD2455778AA87A7346289D90A4EA4F88 51F7457B54F0C066AA41684BD5B05B776954A1A66ADC A4A934BEF2A08404549690BC40695278411EC82C92D0 ADBBA5E9F47C09FB344B9A8DFE52DC93D2C47DA2812B BCFF3E159194A99A4766AB077BBDA75AD499AD5A468C 512D4B5255ABA0E9D2EAC040D5BA3859DAACE9A8DAEE F7CAC3F3E32432BB8D3C32B1BDB49B595B1E8D0F96F6 6FB4561DBAF849C7C141AA53C313D2B96389EAE2B755 BA061F545DCF1E5751BEEB5554EE16D5EDE85CD53D63 A18ADEBE5662A64E51B18BE6C8E32347AA1E535E979E 4F4E965E0943A4F74309E289EE2A4FD488953EA121D2 E7AA5BBCD5BB28EF0F55E5A92BF7ABBE5F5C967E7901 EA695345F5CF3CAD9E49BDA4E2A6E7AA0171796AE0F8 93F26CBB156A50FFED32B8DE0C35243243E2CB67C9D0 3A22430BD2645849920CDF9222CF1DF0C888F47E9290 334A3DFF76A48C9CDF5BBD30AC9E244E6CA146F57C58 25C5D7502F86D755A33B5F532F5571A9E466D525F9FC 1135A6D25519B373934A39BB4FC62E99AFC6E566CB2B 3336C8F88CD9F26ACA3C499D9A2A77F9FCD3A7EFEFCF 5B5FFDFDFF59A6EC9D6FFA95FDB367B93FFFF6BF7BDE BC79338B7B5649F994F9EDC8D5D63E1578C755E68FEF F3393AC6E3EAD0DBE3EA8A9DEC0B978F8F8FFDB87515 AD9EBFBE9D977FBB9D45B7DFB03FC4CD5AFDFDB721B7 D4D1DE53E4A6227715B9ADC87D456E2C7267915B8BDC 5BE4E6227717B9BDC8FD456EB0A3BDC3C82D76B4F718 B9C9C85D466E33729F911B8DDC69E45623F71AB9D9C8 DD466E3772BF911B8EDC71E4963BDA7B8EDC74E4AE23 B71DB9EFC88D47EE3C72EB917B8FDC7CE4EE23B71FB9 FF4803900E38DA16203D70B44D40BA80B401E903D208 A413482B905E38DA6620DD40DA81F4036988A3ED88A3 6D09D21347DB14A42B8EB62D485F1C6D6390CE20AD41 7A833407E90ED21EA43F4883900E212D427A843409E9 12D22647DB27A45148A7905621BD429A85740B6917D2 2FA46148C79096213D439A86740D691BD23747DB38A4 7348EB90DE21CD43BAC7DF1AED43FA873410E920D242 47DB43A4898EB68B481B913E228D443AE91C12DB4AA4 974833916E22ED44FA893414E928D252A4A748531D6D 5791B6227D451A8B7416692DD25BA4B9487791F622FD 451A8C74186931D263A4C98EB6CB489B1D6D9F914623 9D465A8DF41A6936D26DA4DD8EB6DF3C6838D271A4E5 48CF91A6235D77B46D47FAEE681B8F741E693DD27BA4 F948F791F623FD473600B203902D80EC01641320BB00 D906C83E70B41B01D9098E762B207B01D90CC86E40B6 03B21F900D81EC08644B207B02D914C8AE40B605B22F 1CEDC6407686A3DD1AC8DE403607B23B90ED81EC0F64 83203B04D922C81E413609B24B906D82EC1364A3203B C5B1E0D6EF97BD826C1664B720DB05D92FC88641760C B265903D836C1A64D720DB06D937C8C641768EA3DD3A C8DE71B49B07D93DC8F641F60FB281901D846C21640F B9FE1F44FF7D1005D8EFB8EDBF088D691ED622CCDD2C 3C3426DCCDAB805F0162E35BFB ) GB.tz.dotat.at. 3412 IN RRSIG TYPE29818 5 4 3600 ( 20190728110326 20190718100326 56700 dotat.at. JMbEh9MzMHhSIuLF+capNcNEkoa5Q2McgQSBpjS84w4v ROpglw84OgCYunhmI5xmxVgqCUHd4+romQK86xvfit9j 4Gs2kHTKOEjcxfvVbxLoUGkjZOe6zBeaT2tXRx/gQnUq +md2j8+NKEbcRi8oL4YdDjdMsmFo5SntpbRd19E= )
;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Thu Jul 18 15:15:18 BST 2019 ;; MSG SIZE rcvd: 2209
Tony.
_______________________________________________ Tzdist-bis mailing list Tzdist-bis@ietf.org https://www.ietf.org/mailman/listinfo/tzdist-bis
Hi Steve,
On 18 Jul 2019, at 15:50, Steve Crocker <steve@shinkuro.com> wrote:
Early in this thread it was mentioned the the time zone database should be served in a fashion similar to DNS. My first thought was the numbers are wildly different. I jotted down a first cut at identifying the relevant operational parameters. Perhaps the people proposing this service can flesh out the quantitative aspects.
My issue isn’t so much the size of entries. Many entries can fit in a DNS packet *without* EDNS0. It wouldn’t be wildly crazy to to use 2k as a good size. The problem is 2k*O(10^9) (and soon O(10^10)) devices X an unknown frequency, because it is in part based on political considerations of the various jurisdictions. The chaos coming to Europe soon will demonstrate this. Also, I don’t think we should swear by the code in devices these days in terms of how they back off or what epsilons they use in their timers. And then there are all the security aspects of that. Shoving this stuff into the DNS would pretty much require DOH everywhere. Eliot
Steve Crocker wrote:
Early in this thread it was mentioned the the time zone database should be served in a fashion similar to DNS. My first thought was the numbers are wildly different. I jotted down a first cut at identifying the relevant operational parameters. Perhaps the people proposing this service can flesh out the quantitative aspects.
Here are some estimates. There is no central TZDIST server now, so all the non-size estimates are for if/when that happens. The estimated rate of change for these numbers is all zero, except for the database size where I'd estimate a growth of 5%/year (this is just off the top of my head). Frequency of database update: 18 times per year has been the worst case since the project started in the 1980s. Recently updates have occurred three to ten times per year. Frequency of access: If we're assuming a pull model like TZDIST with primary and secondary servers, I would expect queries once every hour-or-so from each downstream server that wants to be up-to-date. Usually the response will be "nothing has changed". Required response time: Most clients and servers can be expected to have a (possibly-stale) copy of the data already, which they can fall back on. So I would say "minutes". Required uptime: Again, not crucial. I would say 90% would be enough. For sizes, it depends on data format and whether you want all the data. Size of entire tzdb database (including all time zone history, version info, and legal notices), in minimal source-code (text) form: 111 kB uncompressed, 27 kB compressed via gzip, 22 kB compressed via lzip. Size of entire tzdb database in binary (TZif) form in traditional form: 456 kB uncompressed, 152 kB tar+gzip, 68 kB tar+lzip. This includes all time zone history but omits version info and legal notices. Same size, but with zic's new '-b slim' option that relies on Internet RFC 8536 instead of attempting to work around bugs in older applications: 216 kB uncompressed, 77 kB tar+gzip, 43 kB tar+lzip. I don't know how to compute the size of tzdb converted into iCalendar form, but my guess is that it'd be the same order-of-magnitude as the TZif files. All sizes are for ordinary (POSIX) tzdb, not for the rarely-used leapsecond variant.
On 7/18/19 4:15 PM, Paul Eggert wrote:
Steve Crocker wrote:
Early in this thread it was mentioned the the time zone database should be served in a fashion similar to DNS. My first thought was the numbers are wildly different. I jotted down a first cut at identifying the relevant operational parameters. Perhaps the people proposing this service can flesh out the quantitative aspects.
Here are some estimates. There is no central TZDIST server now, so all the non-size estimates are for if/when that happens. The estimated rate of change for these numbers is all zero, except for the database size where I'd estimate a growth of 5%/year (this is just off the top of my head).
Frequency of database update: 18 times per year has been the worst case since the project started in the 1980s. Recently updates have occurred three to ten times per year.
Frequency of access: If we're assuming a pull model like TZDIST with primary and secondary servers, I would expect queries once every hour-or-so from each downstream server that wants to be up-to-date. Usually the response will be "nothing has changed".
Required response time: Most clients and servers can be expected to have a (possibly-stale) copy of the data already, which they can fall back on. So I would say "minutes".
Required uptime: Again, not crucial. I would say 90% would be enough.
For sizes, it depends on data format and whether you want all the data.
Size of entire tzdb database (including all time zone history, version info, and legal notices), in minimal source-code (text) form: 111 kB uncompressed, 27 kB compressed via gzip, 22 kB compressed via lzip.
Size of entire tzdb database in binary (TZif) form in traditional form: 456 kB uncompressed, 152 kB tar+gzip, 68 kB tar+lzip. This includes all time zone history but omits version info and legal notices.
Same size, but with zic's new '-b slim' option that relies on Internet RFC 8536 instead of attempting to work around bugs in older applications: 216 kB uncompressed, 77 kB tar+gzip, 43 kB tar+lzip.
I don't know how to compute the size of tzdb converted into iCalendar form, but my guess is that it'd be the same order-of-magnitude as the TZif files.
My current set of iCalendar VTIMEZONEs (using symlinks for aliases) is also 77kB tar+gz.
All sizes are for ordinary (POSIX) tzdb, not for the rarely-used leapsecond variant.
_______________________________________________ Tzdist-bis mailing list Tzdist-bis@ietf.org https://www.ietf.org/mailman/listinfo/tzdist-bis
-- Ken Murchison Cyrus Development Team Fastmail US LLC
Paul and Ken, Thanks for these estimates. It doesn’t seem to me the legal verbiage would be part of the regular download, so that would reduce the payload a bit. Steve Sent from my iPhone
On Jul 18, 2019, at 4:26 PM, Ken Murchison <murch@fastmail.com> wrote:
On 7/18/19 4:15 PM, Paul Eggert wrote: Steve Crocker wrote:
Early in this thread it was mentioned the the time zone database should be served in a fashion similar to DNS. My first thought was the numbers are wildly different. I jotted down a first cut at identifying the relevant operational parameters. Perhaps the people proposing this service can flesh out the quantitative aspects.
Here are some estimates. There is no central TZDIST server now, so all the non-size estimates are for if/when that happens. The estimated rate of change for these numbers is all zero, except for the database size where I'd estimate a growth of 5%/year (this is just off the top of my head).
Frequency of database update: 18 times per year has been the worst case since the project started in the 1980s. Recently updates have occurred three to ten times per year.
Frequency of access: If we're assuming a pull model like TZDIST with primary and secondary servers, I would expect queries once every hour-or-so from each downstream server that wants to be up-to-date. Usually the response will be "nothing has changed".
Required response time: Most clients and servers can be expected to have a (possibly-stale) copy of the data already, which they can fall back on. So I would say "minutes".
Required uptime: Again, not crucial. I would say 90% would be enough.
For sizes, it depends on data format and whether you want all the data.
Size of entire tzdb database (including all time zone history, version info, and legal notices), in minimal source-code (text) form: 111 kB uncompressed, 27 kB compressed via gzip, 22 kB compressed via lzip.
Size of entire tzdb database in binary (TZif) form in traditional form: 456 kB uncompressed, 152 kB tar+gzip, 68 kB tar+lzip. This includes all time zone history but omits version info and legal notices.
Same size, but with zic's new '-b slim' option that relies on Internet RFC 8536 instead of attempting to work around bugs in older applications: 216 kB uncompressed, 77 kB tar+gzip, 43 kB tar+lzip.
I don't know how to compute the size of tzdb converted into iCalendar form, but my guess is that it'd be the same order-of-magnitude as the TZif files.
My current set of iCalendar VTIMEZONEs (using symlinks for aliases) is also 77kB tar+gz.
All sizes are for ordinary (POSIX) tzdb, not for the rarely-used leapsecond variant.
_______________________________________________ Tzdist-bis mailing list Tzdist-bis@ietf.org https://www.ietf.org/mailman/listinfo/tzdist-bis
-- Ken Murchison Cyrus Development Team Fastmail US LLC
<murch.vcf>
Steve Crocker wrote:
It doesn’t seem to me the legal verbiage would be part of the regular download, so that would reduce the payload a bit.
Sorry, I shouldn't have distracted the performance discussion by mentioning that verbiage. It's so small that eliminating it isn't worth the effort unless one is trying to win a compression contest. Here's a complete copy of the verbiage: # This zic input file is in the public domain.
:) Sent from my iPhone
On Jul 18, 2019, at 4:51 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
Steve Crocker wrote:
It doesn’t seem to me the legal verbiage would be part of the regular download, so that would reduce the payload a bit.
Sorry, I shouldn't have distracted the performance discussion by mentioning that verbiage. It's so small that eliminating it isn't worth the effort unless one is trying to win a compression contest. Here's a complete copy of the verbiage:
# This zic input file is in the public domain.
Have long thought there would be merit for some sort of on demand updates. This could be implemented in a system more similar to/if not DNS. If you need the rules for a location/zone/city/place you would query for that and in the first place, the DNS servers provided by your ISP or company and if they have that info you get it from them if not they request off the next level up and so on and so on. In DNS the rules could be published in TXT records in much the same way as Google publishes all its net-blocks in DNS so that anybody can query what public addresses they use. Google publish a TXT record with the names of other TXT records which list the netblocks they use (wish Amazon and MS Azure were so internet application friendly). For a time zone, a TXT record could be published giving the number of records (lines) for that zone and then TXT records published with an index suffix on the zone. IANA could maintain these TXT records under their domain with maybe a subdomain per time zone (OMG in a zone file), OR, they could actually delegate this out to designated authorities for geo-political areas.... OK, yep, that would be a political quagmire for some regions of the world so perhaps not. All of this could be done within the existing internet infrastructure and without it impacting IANA systems. The starting point being an RFC to describe it all including the format meanings of the rules themselves. That format would likely need to be less dependent on the definition of and interpretation of white-space; some sort of single delimiter would be nice. "|" would be a candidate. The records would be free of the commentary, that would remain in the current full download from IANA. DNSSEC.... Definitely. Much mischief possible without. Oh and Java / JodaTime, which I have just patched for the Norfolk Island and Fiji changes not yet released by IANA on a couple of hundred JVMs. Neither Java nor JodaTime would need to embed their timezone info any more (when updated to just use DNS) which would save me from that chore. Wishful thinking ? Must have been suggested before. David Wade *Traversing Googles cloud netblocks (thanks Google).* waded@darkhorse:~$ dig +short TXT _cloud-netblocks.googleusercontent.com "v=spf1 include:_cloud-netblocks1.googleusercontent.com include:_ cloud-netblocks2.googleusercontent.com include:_ cloud-netblocks3.googleusercontent.com include:_ cloud-netblocks4.googleusercontent.com include:_ cloud-netblocks5.googleusercontent.com ?all" waded@darkhorse:~$ dig +short TXT _cloud-netblocks1.googleusercontent.com "v=spf1 include:_cloud-netblocks6.googleusercontent.com include:_ cloud-netblocks7.googleusercontent.com ip4:8.34.208.0/20 ip4:8.35.192.0/21 ip4:8.35.200.0/23 ip4:108.59.80.0/20 ip4:108.170.192.0/20 ip4: 108.170.208.0/21 ?all" waded@darkhorse:~$ dig +short TXT _cloud-netblocks1.googleusercontent.com "v=spf1 include:_cloud-netblocks6.googleusercontent.com include:_ cloud-netblocks7.googleusercontent.com ip4:8.34.208.0/20 ip4:8.35.192.0/21 ip4:8.35.200.0/23 ip4:108.59.80.0/20 ip4:108.170.192.0/20 ip4: 108.170.208.0/21 ?all" waded@darkhorse:~$ dig +short TXT _cloud-netblocks2.googleusercontent.com "v=spf1 ip4:162.216.148.0/22 ip4:162.222.176.0/21 ip4:173.255.112.0/20 ip4: 192.158.28.0/22 ip4:199.192.112.0/22 ip4:199.223.232.0/22 ip4: 199.223.236.0/23 ip4:23.236.48.0/20 ip4:23.251.128.0/19 ip4:35.204.0.0/14 ip4:35.208.0.0/13 ?all" waded@darkhorse:~$ dig +short TXT _cloud-netblocks3.googleusercontent.com "v=spf1 ip4:107.167.160.0/19 ip4:107.178.192.0/18 ip4:146.148.2.0/23 ip4: 146.148.4.0/22 ip4:146.148.8.0/21 ip4:146.148.16.0/20 ip4:146.148.32.0/19 ip4:146.148.64.0/18 ip4:34.104.0.0/22 ?all" waded@darkhorse:~$ dig +short TXT _cloud-netblocks4.googleusercontent.com "v=spf1 ip4:130.211.8.0/21 ip4:130.211.16.0/20 ip4:130.211.32.0/19 ip4: 130.211.64.0/18 ip4:130.211.128.0/17 ip4:104.154.0.0/15 ip4:104.196.0.0/14 ip4:208.68.108.0/23 ip4:35.184.0.0/14 ip4:35.188.0.0/15 ip4:35.216.0.0/15 ?all" waded@darkhorse:~$ dig +short TXT _cloud-netblocks5.googleusercontent.com "v=spf1 ip4:35.190.0.0/17 ip4:35.190.128.0/18 ip4:35.190.192.0/19 ip4: 35.235.224.0/20 ip4:35.192.0.0/14 ip4:35.196.0.0/15 ip4:35.198.0.0/16 ip4: 35.199.0.0/17 ip4:35.199.128.0/18 ip4:35.200.0.0/14 ip4:35.235.216.0/21 ip6:2600:1900::/35 ?all" waded@darkhorse:~$ dig +short TXT _cloud-netblocks6.googleusercontent.com "v=spf1 ip4:35.190.224.0/20 ip4:35.232.0.0/15 ip4:35.234.0.0/16 ip4: 35.235.0.0/17 ip4:35.235.192.0/20 ip4:35.236.0.0/14 ip4:35.240.0.0/15 ip4: 35.203.232.0/21 ip4:130.211.4.0/22 ip4:35.220.0.0/14 ip4:35.242.0.0/15 ip4: 35.244.0.0/14 ?all" waded@darkhorse:~$ dig +short TXT _cloud-netblocks7.googleusercontent.com "v=spf1 ip4:34.64.0.0/11 ip4:34.96.0.0/14 ip4:34.100.0.0/16 ip4: 34.102.0.0/15 ip4:108.170.216.0/22 ip4:108.170.220.0/23 ip4:108.170.222.0/24 ip4:35.224.0.0/13 ip4:35.190.240.0/22 ip4:35.190.242.0/23 ip4:35.206.0.0/15 ?all" On Fri, 19 Jul 2019 at 08:53, Steve Crocker <steve@shinkuro.com> wrote:
:)
Sent from my iPhone
On Jul 18, 2019, at 4:51 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
Steve Crocker wrote:
It doesn’t seem to me the legal verbiage would be part of the regular download, so that would reduce the payload a bit.
Sorry, I shouldn't have distracted the performance discussion by mentioning that verbiage. It's so small that eliminating it isn't worth the effort unless one is trying to win a compression contest. Here's a complete copy of the verbiage:
# This zic input file is in the public domain.
participants (14)
-
Daniel Migault -
Eliot Lear -
Ken Murchison -
Lord Buddha -
Luigi Rosa -
Martin Burnicki -
Matt Johnson -
Michael Douglass -
Paul Eggert -
Paul.Koning＠dell.com -
Philip Paeps -
Steve Crocker -
Thomas Peterson -
Tony Finch