On 7/23/07, Alan Mackenzie <[EMAIL PROTECTED]> wrote:
But "Europe/London" is essentially different from "GMT": It implements
summer time. I don't want summer time on my PC, even if the livin' is
easy. ;-) My PC was set up with "Europe/London" up until yesterday.
I would suggest that you use Etc/UTC if you prefer not to have summer
time, then:
$ for zone in $(
( cd /usr/share/zoneinfo && find * -type f | xargs file | grep
"timezone data" | cut -d: -f1 ) |
xargs ls -i | sort -k1,1 -n -u | awk '{print $2;}' );
do
TZ=$zone date +"%z:$zone"
done |
sort -n | grep "^[-+]0000" | egrep -v "Africa|America|Atlantic"
+0000:Etc/GMT
+0000:Etc/UCT
+0000:Etc/UTC
+0000:Factory
+0000:GMT
+0000:GMT+0
+0000:GMT-0
+0000:GMT0
+0000:Greenwich
+0000:Iceland
+0000:UCT
+0000:UTC
+0000:Universal
+0000:Zulu
+0000:posix/Etc/GMT
+0000:posix/Etc/UCT
+0000:posix/Etc/UTC
+0000:posix/Factory
+0000:right/Etc/GMT
+0000:right/Etc/UCT
+0000:right/Etc/UTC
+0000:right/Factory
I started this thread due to suffering the embarrassment of somebody
pointing out the times in my emails were ~1.5 hours in the future. 1
hour of this somehow came from BST ("British Summer Time")
This definitiely should not be the case. Date stamps in email headers
include the time zone information.
If "date -u" on your machine shows a time which you think is not the
correct UTC time, your system clock (not timezone) configuration is
wrong. Use "hwclock --show" or "hwclock --show --directisa" with
"--localtime" and then with "--utc" to figure out if you had set the
CMOS clock on your machine to local time or to UTC time (I always use
UTC).
It's possible that your CMOS clock is set to local time but you
configured your system to assume it was set to UTC; check
/etc/default/rcS or the equivalent in your dis
, the other
half hour from Debian steadily advancing my CMOS clock over ~1 year by
splatting its system time into the CMOS at every shutdown. I don't
understand the latter process and feel pretty peeved by it, but I'll calm
down after somebody on the debian list explains it to me.
Linux has been set up that way since ~1995. The system clock is often
more accurate than the CMOS clock, and it is certainly easier to check
and maintain its accuracy. You can run NTP for example.
The time mechanism on Linux is too complicated for my taste - I spent
most of yesterday morning trying to get my head round it, and it feels
like time lost rather than useful knowledge gained. There are too many
binary choices interacting with eachother: the CMOS time is either local
or UTC;
Yes. Setting it to UTC is unambiguous and deals robustly withe the
possibility that the syste's default timezone gets changed. But
Windows assumes it is set to local time. Therefore keeping it in
local time is essential for people who dual-boot and keeping it in UTC
is better for those who don't.
we're in normal time or summer time;
Blame the government for that.
TZ is set or unset -
TZ exists to allow individual users to override the system default. I
think having that choice is desirable to be honest.
possibly more. I would rather eliminate this complexity than deal with
it: so my CMOS (like my wristwatch) is set to "GMT", so is my
/etc/timezone, and now I don't have to cope with the vagaries of summer
time (like what happens when you send an email between 2 a.m. and 3 a.m.
in that critical Sunday morning in March?)
Well, if your timezone change occurs then, there is one second between
01:59:59 and 03:00:00. So the time interval to which you refer
doesn't exist, at least in terms of local time.
James.
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
