It is trying to grab delta from 2006.10.29 to 2006.10.29: # emerge-delta-webrsync Looking for available base versions for a delta fetching patches --09:07:47-- http://trumpetti.atm.tut.fi/gentoo///snapshots/deltas/snapshot-20061029-20061029.patch.bz2.md5sum => `/usr/portage/distfiles/snapshot-20061029-20061029.patch.bz2.md5sum' Resolving trumpetti.atm.tut.fi... 130.230.54.100 Connecting to trumpetti.atm.tut.fi|130.230.54.100|:80... connected. HTTP request sent, awaiting response... 404 Not Found 09:07:48 ERROR 404: Not Found. failed fetching snapshot-20061029-20061029.patch.bz2.md5sum # date Tue Oct 31 09:45:41 MSK 2006
Seems like bug in date: # date -d "2006/10/29 +1 day" +"%Y%m%d" 20061029
Seems like this is related to 1 hour timezone changes in Russian during switching to "winter/summer" time: # date -d "2006/10/29 +0 day" Sun Oct 29 00:00:00 MSD 2006 # date -d "2006/10/29 +1 day" Sun Oct 29 23:00:00 MSK 2006
Quick, but dirty fix without touching date: --- ./emerge-delta-webrsync.old 2006-10-31 10:00:06.000000000 +0300 +++ ./emerge-delta-webrsync 2006-10-31 10:00:24.000000000 +0300 @@ -350,7 +350,7 @@ day="${1:6:2}" # if [[ "${USERLAND}" == "BSD" ]] || [[ "${USERLAND}" == "Darwin" ]]; then # else - date -d "$year/$month/$day +1 day" +"%Y%m%d" + date -d "$year/$month/$day +1 day +1 hour" +"%Y%m%d" # fi }
heh. Got this bug too. Maybe not-so-hacky solution would be to use UTC time in next_date because UTC is not affected by daylight saving or decret time or whatever tea@localhost ~ $ LC_ALL=C date -d '2006/10/29 +1 day' Sun Oct 29 23:00:00 MSK 2006 tea@localhost ~ $ LC_ALL=C date -u -d '2006/10/29 +1 day' Mon Oct 30 00:00:00 UTC 2006 PS: Actually summer-to-winter switch point is October, 30, 3AM and not midnight so it looks like small bug in "date". However there are many countries which use daylight saving time, and some of them may use midnight as switch point.
I guess we can add the date -u parameter, but it still seems like a bug in coreutils that should get fixed. What version of coreutils do you all have?
# eix coreutils [I] sys-apps/coreutils Available versions: 5.2.1-r7 ~5.3.0-r2 5.94-r1 ~5.94-r2 ~5.94-r3 ~5.97 ~6.1 ~6.2 ~6.3 ~6.4 Installed: 5.94-r1[10:40:11 05/18/06][-acl -build nls -selinux -static] Going to check with 6.4 soon.
sounds more like a dupe of Bug 130503 ...
I have 5.94-r1 as well. Actually bug 130503 doesn't look any similar to this one
indeed ... on a second look, i'm not sure this is a bug at all when you factor in the timezones, you have to actually add 25 hours to transition a day (which can be broken down into 24 hours) so switching to UTC is the only sane fix ...
from the coreutils manual: You can avoid avoid ambiguities during daylight saving transitions by using utc time stamps.
Thanks Mike. Daylight saving transitions are fun. :)
Just updated coreutils to ~x86 (6.4), seems like it is lacking this issue: # date -d "2006/10/28 +1 day" Sun Oct 29 00:00:00 MSD 2006 # date -d "2006/10/29 +1 day" Mon Oct 30 00:00:00 MSK 2006 # date -d "2006/10/30 +1 day" Tue Oct 31 00:00:00 MSK 2006 # date --version date (GNU coreutils) 6.4 Copyright (C) 2006 Free Software Foundation, Inc. This is free software. You may redistribute copies of it under the terms of the GNU General Public License <http://www.gnu.org/licenses/gpl.html>. There is NO WARRANTY, to the extent permitted by law. Written by David MacKenzie.
Thanks for testing. Anyway, it seems reasonable to expect that a command such as `date -d "2006/10/29 +1 day"` might account for daylight saving transitions, so I'd like to add the -u option anyway.
*** Bug 153574 has been marked as a duplicate of this bug. ***
Created attachment 100970 [details, diff] Using "date -u" in next_date() Hi, some feedback/testing regarding a "date -u" change. Timezone and Daylight-Saving-Time-switching at my location: # date -d '2006-10-29 1:59:59.999999999' +%z_%Z +0200_CEST # date -d '2006-10-29 2:00:00.000000000' +%z_%Z +0100_CET CLOCK Settings: # grep '^CLOCK' /etc/conf.d/clock CLOCK="local" CLOCK_OPTS="" CLOCK_SYSTOHC="no" Using emerge-delta-webrsync-3.5.1-r2 with the following additional patch (also as attachment): # less -F emerge-delta-webrsync-3.5.1-dst.patch --- orig/emerge-delta-webrsync 2006-10-21 00:59:41.000000000 +0200 +++ modified/emerge-delta-webrsync 2006-11-01 12:42:20.000000000 +0100 @@ -356,7 +356,7 @@ day="${1:6:2}" # if [[ "${USERLAND}" == "BSD" ]] || [[ "${USERLAND}" == "Darwin" ]]; then # else - date -d "$year/$month/$day +1 day" +"%Y%m%d" + date -u -d "$year/$month/$day +1 day" +"%Y%m%d" # fi } Results without the patch: 2006-11-01: Update from portage-20061027.tar.bz2: Trying to fetch snapshot-20061029-20061029.patch.bz2.md5sum: Failed (Ctrl-C before full_version_attempt) Results with the mentioned patch: Update from portage-20061027.tar.bz2 to portage-20061030.tar.bz2: ok Update from portage-20061030.tar.bz2 to portage-20061031.tar.bz2: ok Manual checks with *.md5sum, *.umd5sum and *.gpgsig from the mirrors: portage-20061030.tar.bz2: ok portage-20061031.tar.bz2: ok Summary: The patch with "date -u" in next_date() works for me (and my timezone/clock settings). Additional note: Using UTC in all date functions in the script (with some additional modifications in future versions) may improve the usage for users which are not living in the timezone where the gentoo main server is located or where the snapshots are created. Maybe a next version will not try to fetch snapshots which are still dreams of the future for the machine that creates the snapshots. (This may require also a change in the naming scheme of the snapshots.) Quote from /usr/share/doc/timezone-data-2006n/html/tz-art.htm "Don't worry about the world coming to an end today. It is already tomorrow in Australia." (Charles M. Schulz, provided by Steve Summit)
coreutils-6.4 is marked stable now
*** Bug 153787 has been marked as a duplicate of this bug. ***
*** Bug 153898 has been marked as a duplicate of this bug. ***
This is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=76e037f33eeaa4969bae13c6c23eda40566dca39
This is fixed in version 3.6.
