On 05/09/2020 17:25, jdd@dodin.org wrote:
Le 05/09/2020 à 22:44, Istvan Gabor a écrit :
I guess zdump can do something like this.
man zdump:
an often forgotten bash command is "apropos"
apropos timezone [snip] zic (8) - timezone compiler
And there you have the real answer to the question. Somewhere there is the 'source code' that gets compiled into the binary timezone file that Dave was asking about. Actually, while the man page on ZIC says a lot about the source file information, the
tzfile (5) - timezone information gives an almost 1:1 correspondence with the binary values.
The example E.g.: zdump -v -c 2000,2022 Europe/London dumps the result of a range/query and really says little abut that the source file contained It's a but like running a program to give the dates of Easter for the first 30 centuries of the Christian era. The algorithm and the specific years things might have changed (such as the shift to the Gregorian calendar) is there in the source file but the listing of dates is the result of running the program. In the same way, running zdump gives a listing for when the summer time/winter time changes but not the source code, the algorithm. ZIC is the compiler for the source code. https://en.wikipedia.org/wiki/Computus Easter is traditionally celebrated on the first Sunday after the Paschal full moon, which is the first full moon on or after 21 March (an approximation of the March equinox). Determining this date in advance requires a correlation between the lunar months and the solar year, while also accounting for the month, date, and weekday of the calendar. The calculations produce different results depending on whether the Julian calendar or the Gregorian calendar is used. See what I mean? https://c-for-dummies.com/blog/?p=2431 https://www.assa.org.au/edm#Computer There is no real algorithm for dealing with Daylight Saving Time. Basically every country can decide for themselves when -and if- DST starts and ends. The only thing we can do as developers is using some sort of table to look it up. that's why there is the language for specifying the table. The example give was quite narrow. Over the last century and a quarter the British government has altered the dates https://en.wikipedia.org/wiki/British_Summer_Time In the summers of 1941 to 1945, during the Second World War, Britain was two hours ahead of GMT and operating on British Double Summer Time (BDST). ... An inquiry during the winter of 1959–60, in which 180 national organisations were consulted, revealed a slight preference for a change to all-year GMT+1, but instead the length of summer time was extended as a trial. A further inquiry during 1966–1967 led the government of Harold Wilson to introduce the British Standard Time experiment, with Britain remaining on GMT+1 throughout the year. This took place between 27 October 1968 and 31 October 1971, when there was a reversion to the previous arrangement. Politics at work! And more Jacob Rees-Mogg, MP for North East Somerset, tried to introduce an amendment to give Somerset its own time zone, 15 minutes behind London See also https://en.wikipedia.org/wiki/Western_European_Summer_Time And the move to abolish ending summer time, in effect redefining time zones. https://www.bbc.com/news/world-europe-47704345 So now you see what it has to be done with a set of 'rules' that manifest as tables of year ranges and changes. The part of the range table that generates the 88 lines of gmtoff changes in the example is a lot more succinct. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/London -0:01:15 - LMT 1847 Dec 1 0:00s 0:00 GB-Eire %s 1968 Oct 27 1:00 - BST 1971 Oct 31 2:00u 0:00 GB-Eire %s 1996 0:00 EU GMT/BST then, among the EU data, there's a one line entry for 1996 onwards. Succinct, eh? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org