Bob Bib wrote: > Europe/Kiev Thanks. That is critically important.
> $ date --date='@0' > Thu Jan 1 03:00:00 MSK 1970 $ zdump -v Europe/Kiev | less ... Europe/Kiev Fri Nov 5 23:00:00 1943 UTC = Sat Nov 6 02:00:00 1943 MSK isdst=0 gmtoff=10800 Europe/Kiev Tue Mar 31 20:59:59 1981 UTC = Tue Mar 31 23:59:59 1981 MSK isdst=0 gmtoff=10800 Therefore the timezone is listed as MSK. Is that not correct for that time? > > Note that there is no need for quoting those strings above. There are > > no spaces and no special shell characters to protect against. > > Oh, I've just copied the syntax from the date manpage. Ah... Yes. I see that now that you mention it. Thanks. A different and very small issue. > $ date -d "12 Aug 1910 15:00" > Fri Aug 12 15:00:00 KMT 1910 > $ date -d "12 Aug 1910 15:00UTC" > Fri Aug 12 17:02:04 KMT 1910 > $ date -d "12 Aug 1910 15:00UTC" -R > Fri, 12 Aug 1910 17:02:04 +0202 Europe/Kiev Wed Dec 31 21:57:56 1879 UTC = Thu Jan 1 00:00:00 1880 KMT isdst=0 gmtoff=7324 Europe/Kiev Thu May 1 21:57:55 1924 UTC = Thu May 1 23:59:59 1924 KMT isdst=0 gmtoff=7324 Same thing. > I was just playing with old dates; > EET & EEST looked OK, in contrast to MSK, KMT & LMT; > looks like it's not a bug, but a cool feature trying to display the old-style > date/time for a specific location > (not considering Julian / Gregorian calendar variation though). At one time the classic Unix 'cal' command would print the short month of the transition. Unfortunately the Debian version is not so quaint. Okay. I see. This bug would have been better assigned to the tzdata package instead of coreutils. The date command is just the messenger. > Where a table describing all these things like MSK, KMT & LMT can be found? The zdump command prints the specified zone. But if you are doing research then pull the source to the tzdata package and then look at the tables there. They contain many useful comments that have no way to be delivered through. apt-get source tzdata Then look through the files there. Especially the "europe" file. Read the comments. They are very illuminating. Also a good resource is the coreutils FAQ date entry. https://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e If you think the timezones listed in the tzdata are incorrect then please reassign this bug to the tzdata package. If you are satisified that it is all good then we can simply close the bug. Sound good? Bob
signature.asc
Description: Digital signature
