[tz] Hard copy of TZdata2023?

[Alexandre Petrescu]

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
>