Hey, are you aware of any printable or hard copy (paper) publications of your Time-Zone database in a complete or semi-complete form? Perhaps this has been produced by someone in the astrology community? I'm basically looking to see if its possible to get the rights to include parts of such a publication in a publication of my own. I doubt one exists that includes all the info for every city in the world in a single publication, but I'm looking to see if it does and how large it might be. What I have in mind is something that lists information pretty much exactly as its presented in the tables for the "Detailed time zone and clock changes" available on timeanddate.com (minus everything outside the tables): https://www.timeanddate.com/time/zone/canada/vancouver Thanks for any info you can provide! -James Foyle
On 2023-10-14 17:28, natyaveda via tz wrote:
Hey, are you aware of any printable or hard copy (paper) publications of your Time-Zone database in a complete or semi-complete form? Perhaps this has been produced by someone in the astrology community? I'm basically looking to see if its possible to get the rights to include parts of such a publication
I'm not aware of any such publication. The TZDB data files are public-domain, so there's no problem with your generating a publication like that on your own, directly from the data. If you do, please let us know.
Le 15/10/2023 à 02:28, natyaveda via tz a écrit :
Hey, are you aware of any printable or hard copy (paper) publications of your Time-Zone database in a complete or semi-complete form?
I am looking to obtain approximately the same. The full database might be too much to print and read. But a concise form of it, on an A4 or letter sized paper, might be useful. It should be updateable easily, every few months or so. It should contain the capitals and major cities worldwide. Should not contain the past history info. Should list the names in alphabetical order, and with several spellings (local spelling first). It should tell the date of the next few DST changes. Should be printed in a large font. Should be used when Internet is not available. Other than that hard copy, I am also interested to be notified by email about the single next DST change that will happen at a site worldwide (not only at my place). For example, I think now the next DST change (no DST) is going to happen in Europe in November, but not sure whether there are others before that. Alex
Perhaps this has been produced by someone in the astrology community?
I'm basically looking to see if its possible to get the rights to include parts of such a publication in a publication of my own. I doubt one exists that includes all the info for every city in the world in a single publication, but I'm looking to see if it does and how large it might be.
What I have in mind is something that lists information pretty much exactly as its presented in the tables for the "Detailed time zone and clock changes" available on timeanddate.com (minus everything outside the tables):
https://www.timeanddate.com/time/zone/canada/vancouver <https://www.timeanddate.com/time/zone/canada/vancouver>
Thanks for any info you can provide!
-James Foyle
I don't know if it would serve your purposes but there is a list of Tz time zones at Wikipedia if you're not aware of it: List of tz database time zones https://en.wikipedia.org/wiki/List_of_tz_database_time_zones It would be a simple matter to print that list. I'm not sure it's comprehensive, up to date, or who maintains it, but I've not seen any blatant errors and find it usful as a general guide. -Brooks On 2023-10-20 1:27 PM, Alexandre Petrescu via tz wrote:
Le 15/10/2023 à 02:28, natyaveda via tz a écrit :
Hey, are you aware of any printable or hard copy (paper) publications of your Time-Zone database in a complete or semi-complete form?
I am looking to obtain approximately the same.
The full database might be too much to print and read. But a concise form of it, on an A4 or letter sized paper, might be useful. It should be updateable easily, every few months or so. It should contain the capitals and major cities worldwide. Should not contain the past history info. Should list the names in alphabetical order, and with several spellings (local spelling first). It should tell the date of the next few DST changes. Should be printed in a large font. Should be used when Internet is not available.
Other than that hard copy, I am also interested to be notified by email about the single next DST change that will happen at a site worldwide (not only at my place). For example, I think now the next DST change (no DST) is going to happen in Europe in November, but not sure whether there are others before that.
Alex
Perhaps this has been produced by someone in the astrology community?
I'm basically looking to see if its possible to get the rights to include parts of such a publication in a publication of my own. I doubt one exists that includes all the info for every city in the world in a single publication, but I'm looking to see if it does and how large it might be.
What I have in mind is something that lists information pretty much exactly as its presented in the tables for the "Detailed time zone and clock changes" available on timeanddate.com (minus everything outside the tables):
https://www.timeanddate.com/time/zone/canada/vancouver <https://www.timeanddate.com/time/zone/canada/vancouver>
Thanks for any info you can provide!
-James Foyle
On Fri, 20 Oct 2023 at 13:27, Alexandre Petrescu via tz <tz@iana.org> wrote:
I am also interested to be notified by email about the single next DST change that will happen at a site worldwide (not only at my place). For example, I think now the next DST change (no DST) is going to happen in Europe in November, but not sure whether there are others before that.
timeanddate.com publishes detailed listings of all their known DST changes for each half-year, ordered by wall-clock date-time: https://www.timeanddate.com/time/dst/2023b.html https://www.timeanddate.com/time/dst/2024a.html -- Tim Parenti
On 2023-10-20 3:19 PM, Tim Parenti via tz wrote:
On Fri, 20 Oct 2023 at 13:27, Alexandre Petrescu via tz <tz@iana.org <mailto:tz@iana.org>> wrote:
I am also interested to be notified by email about the single next DST change that will happen at a site worldwide (not only at my place). For example, I think now the next DST change (no DST) is going to happen in Europe in November, but not sure whether there are others before that.
timeanddate.com <http://timeanddate.com> publishes detailed listings of all their known DST changes for each half-year, ordered by wall-clock date-time: https://www.timeanddate.com/time/dst/2023b.html https://www.timeanddate.com/time/dst/2024a.html
-- Tim Parenti
Ah! Very nice! Time and Date does a very good job. I use it all the time to help me decipher the intricacies of the TzDb source files. Thanks. -Brooks
Le 20/10/2023 à 21:19, Tim Parenti a écrit :
On Fri, 20 Oct 2023 at 13:27, Alexandre Petrescu via tz <tz@iana.org> wrote:
I am also interested to be notified by email about the single next DST change that will happen at a site worldwide (not only at my place). For example, I think now the next DST change (no DST) is going to happen in Europe in November, but not sure whether there are others before that.
timeanddate.com <http://timeanddate.com> publishes detailed listings of all their known DST changes for each half-year, ordered by wall-clock date-time: https://www.timeanddate.com/time/dst/2023b.html https://www.timeanddate.com/time/dst/2024a.html
Thanks for the pointers. Hopefully they, timeanddate.com, keep up to date fast with the discussions here. After searching the table, I see the next DST change is in Egypt on Oct 27th. It's good to know. Alex
-- Tim Parenti
On 2023-10-20 11:27, Alexandre Petrescu via tz wrote:
Le 15/10/2023 à 02:28, natyaveda via tz a écrit :
Hey, are you aware of any printable or hard copy (paper) publications of your Time-Zone database in a complete or semi-complete form? Perhaps this has been produced by someone in the astrology community? I'm basically looking to see if its possible to get the rights to include parts of such a publication in a publication of my own. I doubt one exists that includes all the info for every city in the world in a single publication, but I'm looking to see if it does and how large it might be. What I have in mind is something that lists information pretty much exactly as its presented in the tables for the "Detailed time zone and clock changes" available on timeanddate.com (minus everything outside the tables): <https://www.timeanddate.com/time/zone/canada/vancouver>
I am looking to obtain approximately the same. The full database might be too much to print and read. But a concise form of it, on an A4 or letter sized paper, might be useful. It should be updateable easily, every few months or so. It should contain the capitals and major cities worldwide. Should not contain the past history info. Should list the names in alphabetical order, and with several spellings (local spelling first). It should tell the date of the next few DST changes. Should be printed in a large font. Should be used when Internet is not available. > Other than that hard copy, I am also interested to be notified by email about the single next DST change that will happen at a site worldwide (not only at my place). For example, I think now the next DST change (no DST) is going to happen in Europe in November, but not sure whether there are others before that. I have defined a zdump alias for interactive use (below) which searches backwards for the first transition in the given zone (or local time) from this year, displaying them up to the start of next year (whose data is not included in any output), which you may be able to adapt by iterating thru all zones of interest, which could just be symlinks to zoneinfo in some directory as in the examples at the top of the shell commands and output.
And seriously *hardcopy*, in this century (other than for tax backups, which are still based on Roman technology)?! At least generate markdown or html which can be displayed locally in a browser, or converted to a digital document using pandoc, htmldoc, or similar. Then you can run this generation process whenever a new tz release is detected automatically, so it is always up to date. # zdump interesting zones using alias or script then post-process $ ln -st ./interested/ /usr/share/zoneinfo/Europe/Brussels ... # symlink zones $ for tz in ./interested/*; do zdump $tz; done | process # output zones $ which zdump # interactive alias zdump () { local z=${@:-${TZ:-/etc/localtime}} y=$(date +%Y); local e=$(($y+1)) b p l t; for b in $y 1970 1900 1752; do range=-Vc$b,$e; p=$(command /usr/bin/zdump $range $z); [ -n "$p" ] && break; done; l=${p##*' '}; t=${l##*[012][0-9]:[0-5][0-9]:[0-6][0-9] }; b=${t:0:4}; if [ -n "$b" ]; then range=-Vc$b,$e; [ $b -lt $y ] && p=$(command /usr/bin/zdump $range $z); else range=''; p=$(command /usr/bin/zdump $range $z); fi; [ -n "$range" ] && echo zdump $range $z; echo "$p" } # zdump alias example outputs $ zdump Europe/Brussels zdump -Vc2023,2024 Europe/Brussels Europe/Brussels Sun Mar 26 00:59:59 2023 UT = Sun Mar 26 01:59:59 2023 CET isdst=0 gmtoff=3600 Europe/Brussels Sun Mar 26 01:00:00 2023 UT = Sun Mar 26 03:00:00 2023 CEST isdst=1 gmtoff=7200 Europe/Brussels Sun Oct 29 00:59:59 2023 UT = Sun Oct 29 02:59:59 2023 CEST isdst=1 gmtoff=7200 Europe/Brussels Sun Oct 29 01:00:00 2023 UT = Sun Oct 29 02:00:00 2023 CET isdst=0 gmtoff=3600 $ zdump zdump -Vc2023,2024 America/Edmonton America/Edmonton Sun Mar 12 08:59:59 2023 UT = Sun Mar 12 01:59:59 2023 MST isdst=0 gmtoff=-25200 America/Edmonton Sun Mar 12 09:00:00 2023 UT = Sun Mar 12 03:00:00 2023 MDT isdst=1 gmtoff=-21600 America/Edmonton Sun Nov 5 07:59:59 2023 UT = Sun Nov 5 01:59:59 2023 MDT isdst=1 gmtoff=-21600 America/Edmonton Sun Nov 5 08:00:00 2023 UT = Sun Nov 5 01:00:00 2023 MST isdst=0 gmtoff=-25200 $ zdump America/Regina zdump -Vc1960,2024 America/Regina America/Regina Sun Apr 24 08:59:59 1960 UT = Sun Apr 24 01:59:59 1960 MST isdst=0 gmtoff=-25200 America/Regina Sun Apr 24 09:00:00 1960 UT = Sun Apr 24 03:00:00 1960 CST isdst=0 gmtoff=-21600 -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Le 20/10/2023 à 21:46, Brian Inglis via tz a écrit :
On 2023-10-20 11:27, Alexandre Petrescu via tz wrote:
Le 15/10/2023 à 02:28, natyaveda via tz a écrit :
Hey, are you aware of any printable or hard copy (paper) publications of your Time-Zone database in a complete or semi-complete form? Perhaps this has been produced by someone in the astrology community? I'm basically looking to see if its possible to get the rights to include parts of such a publication in a publication of my own. I doubt one exists that includes all the info for every city in the world in a single publication, but I'm looking to see if it does and how large it might be. What I have in mind is something that lists information pretty much exactly as its presented in the tables for the "Detailed time zone and clock changes" available on timeanddate.com (minus everything outside the tables): <https://www.timeanddate.com/time/zone/canada/vancouver>
I am looking to obtain approximately the same. The full database might be too much to print and read. But a concise form of it, on an A4 or letter sized paper, might be useful. It should be updateable easily, every few months or so. It should contain the capitals and major cities worldwide. Should not contain the past history info. Should list the names in alphabetical order, and with several spellings (local spelling first). It should tell the date of the next few DST changes. Should be printed in a large font. Should be used when Internet is not available. > Other than that hard copy, I am also interested to be notified by email about the single next DST change that will happen at a site worldwide (not only at my place). For example, I think now the next DST change (no DST) is going to happen in Europe in November, but not sure whether there are others before that. I have defined a zdump alias for interactive use (below) which searches backwards for the first transition in the given zone (or local time) from this year,
Thanks for the zdump commands. I am interested very much in that -Vc2023,2024 option. But the names of the timezones are a much more difficult matter. The names of cities, countries or regions are so difficult to identify. It comes down to manually grepping 'city' to identify the continent file, and then vi to search for the Zone. The principal difficulty in this is to write down 'city' in the right way; and that way is not necessarily the correct way of writing 'city'. There is an additional difficulty in identifying _which_ city is representative for a particular place whose time and DST I need, but that is a geography problem. When I came here I thought it would be easy to find the timezones and DSTs of some places, but it's not that simple. What stays good is that zdump command, provided I know the correct Zone. Thanks for the files and commands! Alex
displaying them up to the start of next year (whose data is not included in any output), which you may be able to adapt by iterating thru all zones of interest, which could just be symlinks to zoneinfo in some directory as in the examples at the top of the shell commands and output.
And seriously *hardcopy*, in this century (other than for tax backups, which are still based on Roman technology)?! At least generate markdown or html which can be displayed locally in a browser, or converted to a digital document using pandoc, htmldoc, or similar. Then you can run this generation process whenever a new tz release is detected automatically, so it is always up to date.
# zdump interesting zones using alias or script then post-process $ ln -st ./interested/ /usr/share/zoneinfo/Europe/Brussels ... # symlink zones $ for tz in ./interested/*; do zdump $tz; done | process # output zones
$ which zdump # interactive alias zdump () { local z=${@:-${TZ:-/etc/localtime}} y=$(date +%Y); local e=$(($y+1)) b p l t;
for b in $y 1970 1900 1752; do range=-Vc$b,$e; p=$(command /usr/bin/zdump $range $z); [ -n "$p" ] && break; done;
l=${p##*' '}; t=${l##*[012][0-9]:[0-5][0-9]:[0-6][0-9] }; b=${t:0:4};
if [ -n "$b" ]; then range=-Vc$b,$e; [ $b -lt $y ] && p=$(command /usr/bin/zdump $range $z); else range=''; p=$(command /usr/bin/zdump $range $z); fi;
[ -n "$range" ] && echo zdump $range $z;
echo "$p" }
# zdump alias example outputs
$ zdump Europe/Brussels zdump -Vc2023,2024 Europe/Brussels Europe/Brussels Sun Mar 26 00:59:59 2023 UT = Sun Mar 26 01:59:59 2023 CET isdst=0 gmtoff=3600 Europe/Brussels Sun Mar 26 01:00:00 2023 UT = Sun Mar 26 03:00:00 2023 CEST isdst=1 gmtoff=7200 Europe/Brussels Sun Oct 29 00:59:59 2023 UT = Sun Oct 29 02:59:59 2023 CEST isdst=1 gmtoff=7200 Europe/Brussels Sun Oct 29 01:00:00 2023 UT = Sun Oct 29 02:00:00 2023 CET isdst=0 gmtoff=3600
$ zdump zdump -Vc2023,2024 America/Edmonton America/Edmonton Sun Mar 12 08:59:59 2023 UT = Sun Mar 12 01:59:59 2023 MST isdst=0 gmtoff=-25200 America/Edmonton Sun Mar 12 09:00:00 2023 UT = Sun Mar 12 03:00:00 2023 MDT isdst=1 gmtoff=-21600 America/Edmonton Sun Nov 5 07:59:59 2023 UT = Sun Nov 5 01:59:59 2023 MDT isdst=1 gmtoff=-21600 America/Edmonton Sun Nov 5 08:00:00 2023 UT = Sun Nov 5 01:00:00 2023 MST isdst=0 gmtoff=-25200
$ zdump America/Regina zdump -Vc1960,2024 America/Regina America/Regina Sun Apr 24 08:59:59 1960 UT = Sun Apr 24 01:59:59 1960 MST isdst=0 gmtoff=-25200 America/Regina Sun Apr 24 09:00:00 1960 UT = Sun Apr 24 03:00:00 1960 CST isdst=0 gmtoff=-21600
Alexandre Petrescu wrote:
But the names of the timezones are a much more difficult matter. The names of cities, countries or regions are so difficult to identify. It comes down to manually grepping 'city' to identify the continent file, and then vi to search for the Zone. The principal difficulty in this is to write down 'city' in the right way; and that way is not necessarily the correct way of writing 'city'. There is an additional difficulty in identifying _which_ city is representative for a particular place whose time and DST I need, but that is a geography problem.
GeoNames (https://www.geonames.org/) is your friend. It lists millions of places, each with an associated tzid, and most with a variety of localized names.
Additionally, one might not have a usable computer to store that data to. So all one could do is to rely on printed tables of most recent timezone data that was available when Internet was last available.
Well, sure, if you can’t even assume the existence of a computer, then school’s pretty much out. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org
On Oct 20, 2023, at 2:21 PM, Doug Ewell via tz <tz@iana.org> wrote:
GeoNames (https://www.geonames.org/) is your friend.
Unless you have their data locally, along with a program to access it, it's only your friend if you have Internet access.
On Oct 20, 2023, at 1:40 PM, Doug Ewell via tz <tz@iana.org> wrote:
Alexandre Petrescu wrote:
Should be used when Internet is not available.
I would guess that very few systems depend on Internet connectivity to access the current tz database. Storing it locally seems much more sensible.
Yes, many users of the tzdb use a local copy. That's true of most if not all UN*Xes that use it (including Android and iOS); updates may be downloaded over the Internet, but little if any software goes out over the Internet every time it needs to convert between local time and UTC. That's probably also true of applications, etc., that use the tzdb.
Le 20/10/2023 à 22:40, Doug Ewell a écrit :
Alexandre Petrescu wrote:
Should be used when Internet is not available. I would guess that very few systems depend on Internet connectivity to access the current tz database. Storing it locally seems much more sensible.
Sure. It should come from the Internet and stored locally. One would like to store it locally once one sees an email declaration from a gov't on this list, and not necessarily fast continuous updates. But in that, one assumes Internet access is readily available when one needs it. This might not be the case. One might need to know now the date of some place, without having Internet access. Additionally, one might not have a usable computer to store that data to. So all one could do is to rely on printed tables of most recent timezone data that was available when Internet was last available. Alex
-- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org
On Oct 20, 2023, at 2:04 PM, Alexandre Petrescu via tz <tz@iana.org> wrote:
Le 20/10/2023 à 22:40, Doug Ewell a écrit :
Alexandre Petrescu wrote:
Should be used when Internet is not available. I would guess that very few systems depend on Internet connectivity to access the current tz database. Storing it locally seems much more sensible.
Sure. It should come from the Internet and stored locally.
On my system, running macOS, the tzdb originally came pre-installed. Both operating system updates and tzdb data updates do, indeed, come from the Internet, and are stored locally.
One would like to store it locally once one sees an email declaration from a gov't on this list, and not necessarily fast continuous updates.
The tzdb isn't continuously updated. New versions are produced as necessary; the tzdb home page: https://www.iana.org/time-zones indicated that the current official is 2023c, released 2023-03-28, so the last update was almost 7 months ago.
But in that, one assumes Internet access is readily available when one needs it.
"When one needs it" is "when the tzdb is updated"; that, as noted, hasn't happened for almost 7 months. As there aren't continuous updates to the tzdb, continuous Internet access is not necessary.
This might not be the case. One might need to know now the date of some place, without having Internet access.
<turns Wi-Fi off to completely remove Internet access> <goes to a Terminal.app window> <types TZ=Europe/Berlin date> Fri Oct 20 23:13:58 CEST 2023 So, yes, indeed, at least if you know the tzid for the tzdb region containing that place, you can know the date and time at that place without having Internet access. With additional local data and software to let you look up the place and get the tzid, it would be even easier, but "place -> tzid" is not part of the scope of the tzdb. The Clock app on my Mac, running Ventura, has a "World Clock" pane that lets me select a city, from a list that includes more than just the cities used to form tzids (but that doesn't, for example, include Christchurch, New Zealand, for some reason, even though it includes the city in which I live). It works even with my Internet access turned off. The same applies to the Clock app on my iPhone, even with both wi-fi and cellular data turned off. The same may apply to third-party apps for both platforms, as well as built-in and third-party apps on Android and various clock apps for other platforms.
Additionally, one might not have a usable computer to store that data to.
That's a different issue. If you don't have a usable computer (where "computer" includes "smartphone", as per the above), you probably lack Internet access, and also probably lack anything that could *use* the data, so, yes, a printed table would be necessary.
So all one could do is to rely on printed tables of most recent timezone data that was available when Internet was last available.
As per my other mail, what you would want is a printed table of *compiled versions of* recent timezone data. The tzdb does *not* consist of a list of time transitions, it consists of a list of rule and zone information from which the transitions can be calculated. The zic command compiles those into binary lists of transitions, and, as has been noted here, current versions of the zdump command can dump out those lists in a somewhat human-readable form.
On 2023-10-20 15:32, Guy Harris via tz wrote:
On Oct 20, 2023, at 2:04 PM, Alexandre Petrescu via tz wrote:
Le 20/10/2023 à 22:40, Doug Ewell a écrit :
Alexandre Petrescu wrote:
Should be used when Internet is not available. I would guess that very few systems depend on Internet connectivity to access the current tz database. Storing it locally seems much more sensible. Sure. It should come from the Internet and stored locally. On my system, running macOS, the tzdb originally came pre-installed. Both operating system updates and tzdb data updates do, indeed, come from the Internet, and are stored locally. One would like to store it locally once one sees an email declaration from a gov't on this list, and not necessarily fast continuous updates. The tzdb isn't continuously updated. New versions are produced as necessary; the tzdb home page: https://www.iana.org/time-zones indicated that the current official is 2023c, released 2023-03-28, so the last update was almost 7 months ago.
Releases are dated and labelled at: https://github.com/eggert/tz/tags
But in that, one assumes Internet access is readily available when one needs it. "When one needs it" is "when the tzdb is updated"; that, as noted, hasn't happened for almost 7 months. As there aren't continuous updates to the tzdb, continuous Internet access is not necessary. This might not be the case. One might need to know now the date of some place, without having Internet access. <turns Wi-Fi off to completely remove Internet access> <goes to a Terminal.app window> <types TZ=Europe/Berlin date> Fri Oct 20 23:13:58 CEST 2023 So, yes, indeed, at least if you know the tzid for the tzdb region containing that place, you can know the date and time at that place without having Internet access. With additional local data and software to let you look up the place and get the tzid, it would be even easier, but "place -> tzid" is not part of the scope of the tzdb. The Clock app on my Mac, running Ventura, has a "World Clock" pane that lets me select a city, from a list that includes more than just the cities used to form tzids (but that doesn't, for example, include Christchurch, New Zealand, for some reason, even though it includes the city in which I live). It works even with my Internet access turned off. The same applies to the Clock app on my iPhone, even with both wi-fi and cellular data turned off. The same may apply to third-party apps for both platforms, as well as built-in and third-party apps on Android and various clock apps for other platforms. Additionally, one might not have a usable computer to store that data to. That's a different issue. If you don't have a usable computer (where "computer" includes "smartphone", as per the above), you probably lack Internet access, and also probably lack anything that could *use* the data, so, yes, a printed table would be necessary. So all one could do is to rely on printed tables of most recent timezone data that was available when Internet was last available. As per my other mail, what you would want is a printed table of *compiled versions of* recent timezone data. The tzdb does *not* consist of a list of time transitions, it consists of a list of rule and zone information from which the transitions can be calculated. The zic command compiles those into binary lists of transitions, and, as has been noted here, current versions of the zdump command can dump out those lists in a somewhat human-readable form.
If you don't have a computer, why would you need timezone data? A watch is fine. Until you get involved with computers, and time, projects like this, and NTP, and GPS receivers, computers to process their data, tell you the precise time, keep their stats, calculate their RMS, standard, Allen, and Hadamard deviations to the nearest [munpf]s, depending on your background, and the offsets from that in every zone in the world. Aargh! ;^> -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
Le 22/10/2023 à 02:37, Brian Inglis via tz a écrit :
On 2023-10-20 15:32, Guy Harris via tz wrote:
On Oct 20, 2023, at 2:04 PM, Alexandre Petrescu via tz wrote:
Le 20/10/2023 à 22:40, Doug Ewell a écrit :
Alexandre Petrescu wrote:
Should be used when Internet is not available. I would guess that very few systems depend on Internet connectivity to access the current tz database. Storing it locally seems much more sensible. Sure. It should come from the Internet and stored locally. On my system, running macOS, the tzdb originally came pre-installed. Both operating system updates and tzdb data updates do, indeed, come from the Internet, and are stored locally. One would like to store it locally once one sees an email declaration from a gov't on this list, and not necessarily fast continuous updates. The tzdb isn't continuously updated. New versions are produced as necessary; the tzdb home page: https://www.iana.org/time-zones indicated that the current official is 2023c, released 2023-03-28, so the last update was almost 7 months ago.
Releases are dated and labelled at:
https://github.com/eggert/tz/tags
But in that, one assumes Internet access is readily available when one needs it. "When one needs it" is "when the tzdb is updated"; that, as noted, hasn't happened for almost 7 months. As there aren't continuous updates to the tzdb, continuous Internet access is not necessary. This might not be the case. One might need to know now the date of some place, without having Internet access. <turns Wi-Fi off to completely remove Internet access> <goes to a Terminal.app window> <types TZ=Europe/Berlin date> Fri Oct 20 23:13:58 CEST 2023 So, yes, indeed, at least if you know the tzid for the tzdb region containing that place, you can know the date and time at that place without having Internet access. With additional local data and software to let you look up the place and get the tzid, it would be even easier, but "place -> tzid" is not part of the scope of the tzdb. The Clock app on my Mac, running Ventura, has a "World Clock" pane that lets me select a city, from a list that includes more than just the cities used to form tzids (but that doesn't, for example, include Christchurch, New Zealand, for some reason, even though it includes the city in which I live). It works even with my Internet access turned off. The same applies to the Clock app on my iPhone, even with both wi-fi and cellular data turned off. The same may apply to third-party apps for both platforms, as well as built-in and third-party apps on Android and various clock apps for other platforms. Additionally, one might not have a usable computer to store that data to. That's a different issue. If you don't have a usable computer (where "computer" includes "smartphone", as per the above), you probably lack Internet access, and also probably lack anything that could *use* the data, so, yes, a printed table would be necessary. So all one could do is to rely on printed tables of most recent timezone data that was available when Internet was last available. As per my other mail, what you would want is a printed table of *compiled versions of* recent timezone data. The tzdb does *not* consist of a list of time transitions, it consists of a list of rule and zone information from which the transitions can be calculated. The zic command compiles those into binary lists of transitions, and, as has been noted here, current versions of the zdump command can dump out those lists in a somewhat human-readable form.
If you don't have a computer, why would you need timezone data? A watch is fine.
Smartwatches need recharge. Simpler electronic watches that keep timezones hard-code the DST changes, and thus need regular update of the DST date changes after manufacturing. Watches receiving time signals (DCF in central Europe) are subject to security attacks (I suppose), and, anyways, see the DST changes only of that particular region. They also depend on the signal visibility wherever that is used (long waves hardly penetrate in many places where people live).
Until you get involved with computers, and time, projects like this,
This is a great project and I am happy how it works, where it is hosted, and other aspects. However, people communicate dates and times by many other long-range communication media than the Internet. One sees dates and times communicated on TV, on the phone, on ham radio and many other non-Internet media. These work ok when Internet access is not working. Correctly correlating events, especially during delicate moments such as DST regular changes but also during the ever more migrations away from it, is a help. Many computers still bug during these delicate events. Microsoft outlook was the most recent I heard of in the public, but it is not the only one.
and NTP, and GPS receivers, computers to process their data, tell you the precise time, keep their stats, calculate their RMS, standard, Allen, and Hadamard deviations to the nearest [munpf]s, depending on your background, and the offsets from that in every zone in the world. Aargh! ;^>
Computers are great, but they need be backed up by some non-computer, in the sense of trusting but verifying. (hadamard deviation... I'll have to look that up). Alex
Le 22/10/2023 à 12:25, Alexandre Petrescu via tz a écrit :
Le 22/10/2023 à 02:37, Brian Inglis via tz a écrit :
On 2023-10-20 15:32, Guy Harris via tz wrote:
On Oct 20, 2023, at 2:04 PM, Alexandre Petrescu via tz wrote:
Le 20/10/2023 à 22:40, Doug Ewell a écrit :
Alexandre Petrescu wrote:
Should be used when Internet is not available. I would guess that very few systems depend on Internet connectivity to access the current tz database. Storing it locally seems much more sensible. Sure. It should come from the Internet and stored locally. On my system, running macOS, the tzdb originally came pre-installed. Both operating system updates and tzdb data updates do, indeed, come from the Internet, and are stored locally. One would like to store it locally once one sees an email declaration from a gov't on this list, and not necessarily fast continuous updates. The tzdb isn't continuously updated. New versions are produced as necessary; the tzdb home page: https://www.iana.org/time-zones indicated that the current official is 2023c, released 2023-03-28, so the last update was almost 7 months ago.
Releases are dated and labelled at:
https://github.com/eggert/tz/tags
But in that, one assumes Internet access is readily available when one needs it. "When one needs it" is "when the tzdb is updated"; that, as noted, hasn't happened for almost 7 months. As there aren't continuous updates to the tzdb, continuous Internet access is not necessary. This might not be the case. One might need to know now the date of some place, without having Internet access. <turns Wi-Fi off to completely remove Internet access> <goes to a Terminal.app window> <types TZ=Europe/Berlin date> Fri Oct 20 23:13:58 CEST 2023 So, yes, indeed, at least if you know the tzid for the tzdb region containing that place, you can know the date and time at that place without having Internet access. With additional local data and software to let you look up the place and get the tzid, it would be even easier, but "place -> tzid" is not part of the scope of the tzdb. The Clock app on my Mac, running Ventura, has a "World Clock" pane that lets me select a city, from a list that includes more than just the cities used to form tzids (but that doesn't, for example, include Christchurch, New Zealand, for some reason, even though it includes the city in which I live). It works even with my Internet access turned off. The same applies to the Clock app on my iPhone, even with both wi-fi and cellular data turned off. The same may apply to third-party apps for both platforms, as well as built-in and third-party apps on Android and various clock apps for other platforms. Additionally, one might not have a usable computer to store that data to. That's a different issue. If you don't have a usable computer (where "computer" includes "smartphone", as per the above), you probably lack Internet access, and also probably lack anything that could *use* the data, so, yes, a printed table would be necessary. So all one could do is to rely on printed tables of most recent timezone data that was available when Internet was last available. As per my other mail, what you would want is a printed table of *compiled versions of* recent timezone data. The tzdb does *not* consist of a list of time transitions, it consists of a list of rule and zone information from which the transitions can be calculated. The zic command compiles those into binary lists of transitions, and, as has been noted here, current versions of the zdump command can dump out those lists in a somewhat human-readable form.
If you don't have a computer, why would you need timezone data? A watch is fine.
Smartwatches need recharge.
Simpler electronic watches that keep timezones hard-code the DST changes, and thus need regular update of the DST date changes after manufacturing.
Watches receiving time signals (DCF in central Europe) are subject to security attacks (I suppose), and, anyways, see the DST changes only of that particular region. They also depend on the signal visibility wherever that is used (long waves hardly penetrate in many places where people live).
Until you get involved with computers, and time, projects like this,
This is a great project and I am happy how it works, where it is hosted, and other aspects.
However, people communicate dates and times by many other long-range communication media than the Internet. One sees dates and times communicated on TV, on the phone, on ham radio and many other non-Internet media. These work ok when Internet access is not working.
Correctly correlating events, especially during delicate moments such as DST regular changes but also during the ever more migrations away from it, is a help.
I meant to say: DST regular changes, migrations away from DST changes, _and_ timezone outright changes (move a region from a timezone to another). These timezone changes seem regular in recent years. I think they are even accelerating. It is important to have the precise current status at hand even if Internet access is not available. When I read the comments about the history, in the tz database, it feels like there were so many changes only around the moment they introduced GMT, and then maybe during world wars. It does not seem to stabilize - independent of the arrival of Internet and computers. On the contrary, it might seem as the Internet and computers actually help to accommodate more and more changes in timezones. Alex
Many computers still bug during these delicate events. Microsoft outlook was the most recent I heard of in the public, but it is not the only one.
and NTP, and GPS receivers, computers to process their data, tell you the precise time, keep their stats, calculate their RMS, standard, Allen, and Hadamard deviations to the nearest [munpf]s, depending on your background, and the offsets from that in every zone in the world. Aargh! ;^>
Computers are great, but they need be backed up by some non-computer, in the sense of trusting but verifying.
(hadamard deviation... I'll have to look that up).
Alex
On 2023-10-22 03:35, Alexandre Petrescu via tz wrote:
These timezone changes seem regular in recent years. I think they are even accelerating.
Yes and no. In some sense there were no "timezone changes" in the 18th century, since time zones did not exist yet. So, yes, things have accelerated since 1800. However, the advent of computer-based timekeeping, starting roughly around 1970, has increased the priority of nailing all this stuff down. 70 years ago it was routine for relatively small locations to have separate rules from their neighbors and to change their rules whenever they felt like it. Nowadays this is generally too much hassle since people's cell phones don't easily track less-formal rule changes like that, which means people have to manually set their cell phones, which is enough hassle that politicians are less likely to change the rules, and even when they try to change the rules they sometimes fail. Recent examples of such failures include Metlakatla in 2019 and Lebanon this year. Even successful changes sometimes require multiple attempts to get it right (such as Mexico last year). Although there are still places and occasions where the hassle of changing the rules appears to be less than the hassle of dealing with clock times that you don't like, I think this is rarer now than it was in the 1960s and 1970s, and it's not clear to me that the tempo is accelerating even if we restrict our attention to the last decade.
On Oct 14, 2023, at 5:28 PM, natyaveda via tz <tz@iana.org> wrote:
Hey, are you aware of any printable or hard copy (paper) publications of your Time-Zone database in a complete or semi-complete form?
Perhaps this has been produced by someone in the astrology community?
I'm basically looking to see if its possible to get the rights to include parts of such a publication in a publication of my own. I doubt one exists that includes all the info for every city in the world in a single publication, but I'm looking to see if it does and how large it might be.
What I have in mind is something that lists information pretty much exactly as its presented in the tables for the "Detailed time zone and clock changes" available on timeanddate.com (minus everything outside the tables):
That page currently shows a table of "Time Changes in Vancouver Over the Years" below it, showing past transitions to and from DST in 2022, past and upcoming transitions in 2023, and upcoming transitions from 2024 to 2026. That information is *NOT* in that form anywhere in the tzdb. A printed version of the most recent release of the tzdb, 2023c, for the tzdb region that includes Vancouver would look like # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule Canada 1918 only - Apr 14 2:00 1:00 D Rule Canada 1918 only - Oct 27 2:00 0 S Rule Canada 1942 only - Feb 9 2:00 1:00 W # War Rule Canada 1945 only - Aug 14 23:00u 1:00 P # Peace Rule Canada 1945 only - Sep 30 2:00 0 S Rule Canada 1974 1986 - Apr lastSun 2:00 1:00 D Rule Canada 1974 2006 - Oct lastSun 2:00 0 S Rule Canada 1987 2006 - Apr Sun>=1 2:00 1:00 D Rule Canada 2007 max - Mar Sun>=8 2:00 1:00 D Rule Canada 2007 max - Nov Sun>=1 2:00 0 S # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule Vanc 1918 only - Apr 14 2:00 1:00 D Rule Vanc 1918 only - Oct 27 2:00 0 S Rule Vanc 1942 only - Feb 9 2:00 1:00 W # War Rule Vanc 1945 only - Aug 14 23:00u 1:00 P # Peace Rule Vanc 1945 only - Sep 30 2:00 0 S Rule Vanc 1946 1986 - Apr lastSun 2:00 1:00 D Rule Vanc 1946 only - Sep 29 2:00 0 S Rule Vanc 1947 1961 - Sep lastSun 2:00 0 S Rule Vanc 1962 2006 - Oct lastSun 2:00 0 S # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone America/Vancouver -8:12:28 - LMT 1884 -8:00 Vanc P%sT 1987 -8:00 Canada P%sT Those are not lists of transitions; they're rules that software can use to *generate* transition times. The *binary* files generated from the source files *do* contain transition times, but they're binary files, so they would need to be interpreted by a program in order to be shown in human-readable form. If what you *really* mean is "are you aware of any printable or hard copy (paper) publications of the DST start and end times for all regions in the tzdb", I don't know of any. Generating such a publication would involve a program that reads the tzdb information, in binary, and displays all the transitions. Newer versions of the zdump command will, with the -V command, show this; for example: $ zdump -c 2026 -V America/Vancouver America/Vancouver Tue Jan 1 08:12:27 1884 UT = Mon Dec 31 23:59:59 1883 LMT isdst=0 gmtoff=-29548 America/Vancouver Tue Jan 1 08:12:28 1884 UT = Tue Jan 1 00:12:28 1884 PST isdst=0 gmtoff=-28800 America/Vancouver Sun Apr 14 09:59:59 1918 UT = Sun Apr 14 01:59:59 1918 PST isdst=0 gmtoff=-28800 America/Vancouver Sun Apr 14 10:00:00 1918 UT = Sun Apr 14 03:00:00 1918 PDT isdst=1 gmtoff=-25200 America/Vancouver Sun Oct 27 08:59:59 1918 UT = Sun Oct 27 01:59:59 1918 PDT isdst=1 gmtoff=-25200 America/Vancouver Sun Oct 27 09:00:00 1918 UT = Sun Oct 27 01:00:00 1918 PST isdst=0 gmtoff=-28800 America/Vancouver Mon Feb 9 09:59:59 1942 UT = Mon Feb 9 01:59:59 1942 PST isdst=0 gmtoff=-28800 America/Vancouver Mon Feb 9 10:00:00 1942 UT = Mon Feb 9 03:00:00 1942 PWT isdst=1 gmtoff=-25200 America/Vancouver Tue Aug 14 22:59:59 1945 UT = Tue Aug 14 15:59:59 1945 PWT isdst=1 gmtoff=-25200 America/Vancouver Tue Aug 14 23:00:00 1945 UT = Tue Aug 14 16:00:00 1945 PPT isdst=1 gmtoff=-25200 America/Vancouver Sun Sep 30 08:59:59 1945 UT = Sun Sep 30 01:59:59 1945 PPT isdst=1 gmtoff=-25200 America/Vancouver Sun Sep 30 09:00:00 1945 UT = Sun Sep 30 01:00:00 1945 PST isdst=0 gmtoff=-28800 America/Vancouver Sun Apr 28 09:59:59 1946 UT = Sun Apr 28 01:59:59 1946 PST isdst=0 gmtoff=-28800 America/Vancouver Sun Apr 28 10:00:00 1946 UT = Sun Apr 28 03:00:00 1946 PDT isdst=1 gmtoff=-25200 America/Vancouver Sun Sep 29 08:59:59 1946 UT = Sun Sep 29 01:59:59 1946 PDT isdst=1 gmtoff=-25200 America/Vancouver Sun Sep 29 09:00:00 1946 UT = Sun Sep 29 01:00:00 1946 PST isdst=0 gmtoff=-28800 ... America/Vancouver Sun Mar 14 09:59:59 2021 UT = Sun Mar 14 01:59:59 2021 PST isdst=0 gmtoff=-28800 America/Vancouver Sun Mar 14 10:00:00 2021 UT = Sun Mar 14 03:00:00 2021 PDT isdst=1 gmtoff=-25200 America/Vancouver Sun Nov 7 08:59:59 2021 UT = Sun Nov 7 01:59:59 2021 PDT isdst=1 gmtoff=-25200 America/Vancouver Sun Nov 7 09:00:00 2021 UT = Sun Nov 7 01:00:00 2021 PST isdst=0 gmtoff=-28800 America/Vancouver Sun Mar 13 09:59:59 2022 UT = Sun Mar 13 01:59:59 2022 PST isdst=0 gmtoff=-28800 America/Vancouver Sun Mar 13 10:00:00 2022 UT = Sun Mar 13 03:00:00 2022 PDT isdst=1 gmtoff=-25200 America/Vancouver Sun Nov 6 08:59:59 2022 UT = Sun Nov 6 01:59:59 2022 PDT isdst=1 gmtoff=-25200 America/Vancouver Sun Nov 6 09:00:00 2022 UT = Sun Nov 6 01:00:00 2022 PST isdst=0 gmtoff=-28800 America/Vancouver Sun Mar 12 09:59:59 2023 UT = Sun Mar 12 01:59:59 2023 PST isdst=0 gmtoff=-28800 America/Vancouver Sun Mar 12 10:00:00 2023 UT = Sun Mar 12 03:00:00 2023 PDT isdst=1 gmtoff=-25200 America/Vancouver Sun Nov 5 08:59:59 2023 UT = Sun Nov 5 01:59:59 2023 PDT isdst=1 gmtoff=-25200 America/Vancouver Sun Nov 5 09:00:00 2023 UT = Sun Nov 5 01:00:00 2023 PST isdst=0 gmtoff=-28800 America/Vancouver Sun Mar 10 09:59:59 2024 UT = Sun Mar 10 01:59:59 2024 PST isdst=0 gmtoff=-28800 America/Vancouver Sun Mar 10 10:00:00 2024 UT = Sun Mar 10 03:00:00 2024 PDT isdst=1 gmtoff=-25200 America/Vancouver Sun Nov 3 08:59:59 2024 UT = Sun Nov 3 01:59:59 2024 PDT isdst=1 gmtoff=-25200 America/Vancouver Sun Nov 3 09:00:00 2024 UT = Sun Nov 3 01:00:00 2024 PST isdst=0 gmtoff=-28800 America/Vancouver Sun Mar 9 09:59:59 2025 UT = Sun Mar 9 01:59:59 2025 PST isdst=0 gmtoff=-28800 America/Vancouver Sun Mar 9 10:00:00 2025 UT = Sun Mar 9 03:00:00 2025 PDT isdst=1 gmtoff=-25200 America/Vancouver Sun Nov 2 08:59:59 2025 UT = Sun Nov 2 01:59:59 2025 PDT isdst=1 gmtoff=-25200 America/Vancouver Sun Nov 2 09:00:00 2025 UT = Sun Nov 2 01:00:00 2025 PST isdst=0 gmtoff=-28800 That could probably be processed to put it in an easier-to-read form.
participants (8)
-
Alexandre Petrescu -
Brian Inglis -
Brooks Harris -
Doug Ewell -
Guy Harris -
natyaveda -
Paul Eggert -
Tim Parenti