rather cosmetic, or ? ==> /usr/portage/metadata/timestamp.x <== 1424432101 Fri 20 Feb 2015 11:35:01 AM UTC UTC
Please post your `emerge --info' output in a comment.
# cat /world/gentoo/portage/metadata/timestamp.x 1424493301 Sat 21 Feb 2015 04:35:01 AM UTC UTC
The metadata/timestamp.x is generated by an infra script on the master rsync mirror.
date's manpage: %c locale's date and time (e.g., Thu Mar 3 23:05:25 2005) /bin/date -u '+%s %c %Z' is the format used; and the scripts haven't changed; There was a coreutils upgrade however, Did the output of %c change in 2014, WITHOUT any update of coreutils, timezone-data or /etc/localtime? portage-20120629.tar.bz2: 1340930101 Fri Jun 29 00:35:01 2012 UTC portage-20130101.tar.bz2: 1357000501 Tue Jan 1 00:35:01 2013 UTC portage-20130601.tar.bz2: 1370046901 Sat Jun 1 00:35:01 2013 UTC portage-20140116.tar.bz2: 1389832501 Thu Jan 16 00:35:01 2014 UTC portage-20140301.tar.bz2: 1393634101 Sat Mar 1 00:35:01 2014 UTC portage-20140315.tar.bz2: 1394757301 Fri Mar 14 00:35:01 2014 UTC portage-20140320.tar.bz2: 1395275701 Thu Mar 20 00:35:01 2014 UTC portage-20140325.tar.bz2: 1395707701 Tue Mar 25 00:35:01 2014 UTC portage-20140326.tar.bz2: 1395794101 Wed 26 Mar 2014 12:35:01 AM UTC UTC portage-20140327.tar.bz2: 1395880501 Thu 27 Mar 2014 12:35:01 AM UTC UTC portage-20140401.tar.bz2: 1396312501 Tue 01 Apr 2014 12:35:01 AM UTC UTC portage-20140601.tar.bz2: 1401582901 Sun 01 Jun 2014 12:35:01 AM UTC UTC Here's the these boxes, March 2014: (grep -e 'Mar 2014' -e glibc -e timezone-data -e coreutils) dipper: Mon, 30 Dec 2013 19:20:29 +0000 ::: completed emerge (1 of 1) sys-libs/glibc-2.16.0 to / Sat, 11 Jan 2014 21:27:25 +0000 ::: completed emerge (1 of 1) sys-libs/timezone-data-2013d to / Sat, 11 Jan 2014 21:29:31 +0000 ::: completed emerge (1 of 1) sys-apps/coreutils-8.21 to / Sun, 09 Mar 2014 14:07:02 +0000 ::: completed emerge (1 of 1) dev-libs/libyaml-0.1.5 to / Tue, 11 Mar 2014 11:04:12 +0000 ::: completed emerge (1 of 2) dev-util/xdelta-3.0.6 to / Tue, 11 Mar 2014 11:04:28 +0000 ::: completed emerge (2 of 2) dev-util/squashmerge-9999 to / Tue, 11 Mar 2014 11:05:01 +0000 ::: completed emerge (1 of 1) dev-util/squashdelta-9999 to / Wed, 12 Mar 2014 11:25:25 +0000 ::: completed emerge (1 of 1) sys-fs/squashfs-tools-4.2 to / Wed, 12 Mar 2014 11:49:49 +0000 ::: completed emerge (1 of 1) sys-fs/squashfs-tools-4.2_p20140119-r1 to / Fri, 14 Mar 2014 18:56:42 +0000 ::: completed emerge (1 of 2) dev-lang/python-exec-2.0.1-r1 to / Fri, 14 Mar 2014 18:57:04 +0000 ::: completed emerge (2 of 2) sys-apps/file-5.17 to / Mon, 24 Mar 2014 17:22:48 +0000 ::: completed emerge (1 of 1) dev-util/squashdelta-9999 to / Tue, 25 Mar 2014 22:50:42 +0000 ::: completed emerge (1 of 1) sys-process/cronie-1.4.11-r1 to / Wed, 26 Mar 2014 20:51:03 +0000 ::: completed emerge (1 of 1) sys-process/cronie-1.4.11-r1 to / Mon, 10 Nov 2014 20:43:23 +0000 ::: completed emerge (1 of 1) sys-libs/timezone-data-2014g to / albatross: Mon, 30 Dec 2013 20:09:15 +0000 ::: completed emerge (1 of 1) sys-libs/glibc-2.16.0 to / Sat, 11 Jan 2014 21:37:12 +0000 ::: completed emerge (1 of 1) sys-libs/timezone-data-2013d to / Sat, 11 Jan 2014 21:40:03 +0000 ::: completed emerge (1 of 1) sys-apps/coreutils-8.21 to / Sun, 09 Mar 2014 14:07:04 +0000 ::: completed emerge (1 of 1) dev-libs/libyaml-0.1.5 to / Fri, 14 Mar 2014 18:56:36 +0000 ::: completed emerge (1 of 2) dev-lang/python-exec-2.0.1-r1 to / Fri, 14 Mar 2014 18:57:05 +0000 ::: completed emerge (2 of 2) sys-apps/file-5.17 to / Tue, 25 Mar 2014 23:13:05 +0000 ::: completed emerge (1 of 1) sys-process/cronie-1.4.11-r1 to / Wed, 26 Mar 2014 20:50:57 +0000 ::: completed emerge (1 of 1) sys-process/cronie-1.4.11-r1 to / Mon, 10 Nov 2014 20:33:43 +0000 ::: completed emerge (1 of 1) sys-libs/timezone-data-2014g to / It seems be centred around the cronie upgrade, which would have restarted cron; but I don't see why that caused it to change. For the moment, I dropped the trailing ' %Z' on the date calls.
(In reply to Robin Johnson from comment #4) tl;dr: an infra env change broke this the `date` command is merely calling strftime("%c"). that means it relies on glibc to return the right answer. glibc will use locale data (not timezone data) to figure out the meaning of %c. the timezone data is merely to figure out offsets to UTC. i.e. "what does 'PST' mean" and "when are leap years/seconds" and "when is daylight savings". it has no l18n information. you can check it on your system: LC_ALL=C date -u +%c LC_ALL=en_US date -u +%c i have an old chroot that also shows the same behavior as my up-to-date host: sys-apps/coreutils-8.16 sys-libs/timezone-data-2012c sys-libs/glibc-2.4-r3 my recommendation: change the script to do: echo "$(date -u +%s)" "$(date -uR)" then locale will never be an issue
(In reply to SpanKY from comment #5) > (In reply to Robin Johnson from comment #4) > > tl;dr: an infra env change broke this > > the `date` command is merely calling strftime("%c"). that means it relies > on glibc to return the right answer. That's what I thought too, but the LC* settings haven't changed in cfengine or puppet for much longer than this. > my recommendation: change the script to do: > echo "$(date -u +%s)" "$(date -uR)" > then locale will never be an issue Portage: can we just change it to something even more reliable, like a proper ISO8601 date+time?
