Andras Korn wrote: > Bob Proulx wrote: > > What is your timezone? > > Europe/Budapest. > > Apparently May 23 1954 was the date something about DST was changed in CET.
$ TZ=Europe/Budapest date -R -d '1954-05-23' date: invalid date ‘1954-05-23’ Yes. For 1954 here is when they changed: $ zdump -v Europe/Budapest | grep 1954 Europe/Budapest Sat May 22 22:59:59 1954 UTC = Sat May 22 23:59:59 1954 CET isdst=0 gmtoff=3600 Europe/Budapest Sat May 22 23:00:00 1954 UTC = Sun May 23 01:00:00 1954 CEST isdst=1 gmtoff=7200 Europe/Budapest Sat Oct 2 21:59:59 1954 UTC = Sat Oct 2 23:59:59 1954 CEST isdst=1 gmtoff=7200 Europe/Budapest Sat Oct 2 22:00:00 1954 UTC = Sat Oct 2 23:00:00 1954 CET isdst=0 gmtoff=3600 And so as you can see DST changed at Sat May 22 23:59:59 1954 CET and jumped directly to Sun May 23 01:00:00 1954 CEST with no "legally" valid seconds between those two times. (This is one of the very few times in software when it is literally an "illegal" value.) To avoid this it would be best to use UTC. > date(1)'s behaviour may in fact be correct, but the error message is > confusing, > as obviously 1954 did have a May 23 even in Central Europe. :) Maybe > the message could be made more specific? Like "1954-05-23T00:00:00 CET is > invalid due to DST" or similar? I would not be opposed to that. I am even motivated to suggest that upstream! > > Please see the FAQ entry which has examples of diagnosing and avoiding > > DST problems: > > > > > > http://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e > > Thanks, but is there any guarantee that no DST changes will ever cause noon > to be skipped? :) No. There is an old saying. "No man's life, liberty, or property are safe while the legislature is in session." Just as a humorous note this is of course an act of law and not technology. :-) That is why timezones are a table lookup and changes whenever people and governments decide to change it. But I know of no timezone that is presently problematic when using 12:00 noon and that provides a nice anchor point for people who wish to work with dates in a specific timezone and not UTC. I think it quite unlikely that anyone would make a DST change at 12:00 noon. The best solution is to UTC. Either use date's -u option or set TZ to UTC as appropriate. FOr this case of the simple -d then using -u is the best solution. $ date -u -R -d '1954-05-23' Sun, 23 May 1954 00:00:00 +0000 $ TZ=UTC date -R -d '1954-05-23' Sun, 23 May 1954 00:00:00 +0000 Doing it that way will avoid all DST problems. Bob -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
