Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
time zone and UTC issue
45 views
Skip to first unread message
J. B
Nov 28, 2012, 5:30:02 AM11/28/12
to
Hello list,
My box is configured to the local time zone from beginning, both hwclock and system time.
But linux always favor hwclock to UTC. What is the advantage of doing that ?
If I need my hwclock to UTC then what should be the right way to do that ?
I have followed "dpkg-reconfigure tzdata" and found it has changed the local time to
UTC too. Confused .....
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20121128155...@shiva.selfip.org
Darac Marjal
Nov 28, 2012, 5:40:02 AM11/28/12
to
On Wed, Nov 28, 2012 at 03:55:16PM +0530, J. B wrote:
>
> Hello list,
>
> My box is configured to the local time zone from beginning, both hwclock and system time.
> But linux always favor hwclock to UTC. What is the advantage of doing that ?
>
> If I need my hwclock to UTC then what should be the right way to do that ?
> I have followed "dpkg-reconfigure tzdata" and found it has changed the local time to
> UTC too. Confused .....
The problem is that the hardware clock doesn't store a timezone, so when
>
> Hello list,
>
> My box is configured to the local time zone from beginning, both hwclock and system time.
> But linux always favor hwclock to UTC. What is the advantage of doing that ?
>
> If I need my hwclock to UTC then what should be the right way to do that ?
> I have followed "dpkg-reconfigure tzdata" and found it has changed the local time to
> UTC too. Confused .....
it reports the time as 10:32, is that 10:32 in your current time zone,
or 10:32 in a standardized time zone (i.e. UTC) or...
Which you choose doesn't really make much difference, so long as all
OSes that update the hwclock agree on what it's set to. You can agree to
keep it in UTC-5 if you like, even if that's NOT your local time zone,
just so long as you tell your system to apply the correct offset when
reading/writing it.
The main issue comes when you're dual-booting with Windows. By default,
that assumes the hwclock reads local time. If Linux thinks it should be
UTC, then you're going to see odd time jumps as you switch between them.
Hope that clarifies things.
J. B
Nov 28, 2012, 5:50:02 AM11/28/12
to
So please advise how can I set hwclock and localtime.
Thanks
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Eike Lantzsch
Nov 28, 2012, 6:30:01 AM11/28/12
to
/etc/default/hwclock
HWCLOCKACCESS=yes
dpkg-reconfigure tzdata
(set to your timezone)
or use /usr/bin/tzselect command
change time with "date" to local time.
OS takes care of the rest, so your hwclock is now set to UTC while date shows local time. TZDATA is updated whenever some countries like Argentina, decide to change the daylight saving time.
this document is not entirely up-to-date:
http://www.debian-administration.org/articles/213
/etc/default/rcS advises:
# assume that the BIOS clock is set to UTC time (recommended)
#UTC=yes # OBSOLETE; see /etc/adjtime and hwclock(8).
my /etc/adjtime right now:
1.868495 1354099078 0.000000
1354099078
UTC
man hwclock
HTH
Kind regards
Eike
--
What is the difference between an optimist and a pessimist?
An optimist thinks that we live in the best of all possible worlds.
A pessimist is afraid that the optimist might be right.
Eike Lantzsch
Nov 28, 2012, 6:50:01 AM11/28/12
to
Yep. Unfortunately Microsoft never learned in > 25 years that the world has more time zones than they might have imagined in DOS-times. The drawback comes when you live in an obscure country with daylight savings time other than main cities like Santiago de Chile or Caracas, Venezuela. Bolivia, Paraguay and many of the different timezones of Brazil are entirely ignored.
GMT +X or -X is just not enough.
This does not only affect double boot systems but also syncing PDAs and Smartphones if you are travelling internationally - even WindowsOS to WindowsOS. It is a pain!
So I learned to ignore the time on Windows systems with double boot. That is pure resignation. Windows does not only include crippleware but also is based on cripple-standards. For me UNIX ist the standard because it works and the ret**ds @ MS can eat their own medicine if they like it that way!
If MS had invented the chronometer ships nowadays still would founder because of navigators being utterly unable to calculate the latitude just like in 16th century. I'd recommend: MS please get a rest on the Scilly Islands!
Kind regards
Eike
Andrei POPESCU
Nov 28, 2012, 7:50:03 AM11/28/12
to
On Mi, 28 nov 12, 08:44:59, Eike Lantzsch wrote:
> So I learned to ignore the time on Windows systems with double boot.
Set it to UTC, that way it is at least partially useful.
> So I learned to ignore the time on Windows systems with double boot.
Kind regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
Ralf Mardorf
Nov 28, 2012, 8:30:03 AM11/28/12
to
On Wed, 2012-11-28 at 15:55 +0530, J. B wrote:
> Hello list,
>
> My box is configured to the local time zone from beginning, both hwclock and system time.
> But linux always favor hwclock to UTC. What is the advantage of doing that ?
>
> If I need my hwclock to UTC then what should be the right way to do that ?
> I have followed "dpkg-reconfigure tzdata" and found it has changed the local time to
> UTC too. Confused .....
The Linux has to know if the hwclock does use UTC or not and then it
> Hello list,
>
> My box is configured to the local time zone from beginning, both hwclock and system time.
> But linux always favor hwclock to UTC. What is the advantage of doing that ?
>
> If I need my hwclock to UTC then what should be the right way to do that ?
> I have followed "dpkg-reconfigure tzdata" and found it has changed the local time to
> UTC too. Confused .....
will set up the clock, when running a Linux to the correct time for your
timezone. IOW you only have to inform what time hwclock does use.
I'm living in Germany, if my hwclock would use UTC time, then saving
e.g. BIOS settings, would add a wrong time to the files. So I can't see
an advantage in using UTC. I'm using local time for the hwclock.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ralf Mardorf
Nov 28, 2012, 8:40:03 AM11/28/12
to
On Wed, 2012-11-28 at 08:44 -0300, Eike Lantzsch wrote:
> Yep. Unfortunately Microsoft never learned in > 25 years that the
> world has more time zones than they might have imagined in DOS-times.
They did and as I already explained, I want to have the local time for
> Yep. Unfortunately Microsoft never learned in > 25 years that the
> world has more time zones than they might have imagined in DOS-times.
the BIOS too.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ralf Mardorf
Nov 28, 2012, 8:40:03 AM11/28/12
to
On Wed, 2012-11-28 at 10:37 +0000, Darac Marjal wrote:
> The main issue comes when you're dual-booting with Windows.
No Windows on my machine, but as explained in my previous mail, I
> The main issue comes when you're dual-booting with Windows.
sometimes store BIOS settings and want the files getting the correct
date.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ralf Mardorf
Nov 28, 2012, 12:30:02 PM11/28/12
to
On Wed, 2012-11-28 at 08:45 -0800, unruh wrote:
> interpret the time using /etc/localtime, usually into localtime. All
> filestamps are raw in UTC but interpreted into localtime. It is just
> silly to have the rtc/bios clock on localtime, and causes problems and
> has absolutely no advantages.
If I save BIOS settings as a file and the hwclock is set to UTC, the
files don't get the German time. The BIOS is the BIOS, it's neither
Windows, I don't use Windows, but nor the BIOS is Linux, so Linux can't
"translate" UTC to local time, when I save BIOS settings.
Under Linux I never noticed any disadvantage, when the hwclock is set to
local time. Why should there be issues?
Regards,
Ralf
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1354122293.3152.31.camel@q
> In linux.debian.user, you wrote:
> > On Wed, 2012-11-28 at 08:44 -0300, Eike Lantzsch wrote:
> >> Yep. Unfortunately Microsoft never learned in > 25 years that the
> >> world has more time zones than they might have imagined in DOS-times.
> >
> > They did and as I already explained, I want to have the local time for
> > the BIOS too.
>
> Why? Linux is designed to run the system time on UTC and to always
> > On Wed, 2012-11-28 at 08:44 -0300, Eike Lantzsch wrote:
> >> Yep. Unfortunately Microsoft never learned in > 25 years that the
> >> world has more time zones than they might have imagined in DOS-times.
> >
> > They did and as I already explained, I want to have the local time for
> > the BIOS too.
>
> interpret the time using /etc/localtime, usually into localtime. All
> filestamps are raw in UTC but interpreted into localtime. It is just
> silly to have the rtc/bios clock on localtime, and causes problems and
> has absolutely no advantages.
If I save BIOS settings as a file and the hwclock is set to UTC, the
files don't get the German time. The BIOS is the BIOS, it's neither
Windows, I don't use Windows, but nor the BIOS is Linux, so Linux can't
"translate" UTC to local time, when I save BIOS settings.
Under Linux I never noticed any disadvantage, when the hwclock is set to
local time. Why should there be issues?
Regards,
Ralf
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
green
Nov 28, 2012, 12:50:02 PM11/28/12
to
Ralf Mardorf wrote at 2012-11-28 11:04 -0600:
> If I save BIOS settings as a file and the hwclock is set to UTC, the
> files don't get the German time. The BIOS is the BIOS, it's neither
> Windows, I don't use Windows, but nor the BIOS is Linux, so Linux can't
> "translate" UTC to local time, when I save BIOS settings.
>
> Under Linux I never noticed any disadvantage, when the hwclock is set to
> local time. Why should there be issues?
Linux uses UTC. Local time is always changing based on time zones and
> If I save BIOS settings as a file and the hwclock is set to UTC, the
> files don't get the German time. The BIOS is the BIOS, it's neither
> Windows, I don't use Windows, but nor the BIOS is Linux, so Linux can't
> "translate" UTC to local time, when I save BIOS settings.
>
> Under Linux I never noticed any disadvantage, when the hwclock is set to
> local time. Why should there be issues?
daylight saving time. Using UTC for the hardware clock (BIOS clock) is the
correct way and works. If you are having trouble with using UTC for the
hardware clock, then it is probably because (1) Windows (if you dual boot) is
changing the time, or (2) you have (or someone/something has) configured
Linux to use local time for the hardware clock, which is possible though not
recommended.
Ralf Mardorf
Nov 28, 2012, 1:40:01 PM11/28/12
to
On Wed, 2012-11-28 at 19:17 +0100, Ralf Mardorf wrote:
> On Wed, 2012-11-28 at 19:12 +0100, Ralf Mardorf wrote:
> > In the sentence from me above I've wrtten taht I don't use Windows.
> >
> > I haven't written that I would get issues when using UTC, but I also
> > don't get issues, when I'm using local time.
> >
> > Nobody did explain how the BIOS should save files with German time, if
> > the clock is set to UTC.
> >
> > Again, some people have a BIOS and do use it ;). Some people save BIOS
> > settings to e.g. USB. No Linux, no Windows, it's just the BIOS.
> >
> > If the clock does use local time, then the time for all BIOS and all
> > Linux files are ok.
> >
> > If the clock is set to local time, then the time for the BIOS files is
> IS NOT SET oops, a typo ;)
> > wrong, only the files for Linux are ok.
> >
> > So, what is better?
> >
> > All files have the wanted, correct time or just Linux files have the
> > correct time?
> >
> > Don't mention Windows again and again.
> >
> > Do you have a BIOS or have you some magic Linux replacement for the
> > BIOS?
> >
> > Regards,
> > Ralf
>
PS: Btw. after statartup I run ntpdate, time for Linux always is
correct, even if I would use something evil, that would set the time
wrong, before startup.
The BIOS is the BIOS, I can't use ntp or manually run sntp, ntpdate or
what ever.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1354126955.3152.42.camel@q
> On Wed, 2012-11-28 at 19:12 +0100, Ralf Mardorf wrote:
> >
> > I haven't written that I would get issues when using UTC, but I also
> > don't get issues, when I'm using local time.
> >
> > Nobody did explain how the BIOS should save files with German time, if
> > the clock is set to UTC.
> >
> > Again, some people have a BIOS and do use it ;). Some people save BIOS
> > settings to e.g. USB. No Linux, no Windows, it's just the BIOS.
> >
> > If the clock does use local time, then the time for all BIOS and all
> > Linux files are ok.
> >
> > If the clock is set to local time, then the time for the BIOS files is
> IS NOT SET oops, a typo ;)
> > wrong, only the files for Linux are ok.
> >
> > So, what is better?
> >
> > All files have the wanted, correct time or just Linux files have the
> > correct time?
> >
> > Don't mention Windows again and again.
> >
> > Do you have a BIOS or have you some magic Linux replacement for the
> > BIOS?
> >
> > Regards,
> > Ralf
>
PS: Btw. after statartup I run ntpdate, time for Linux always is
correct, even if I would use something evil, that would set the time
wrong, before startup.
The BIOS is the BIOS, I can't use ntp or manually run sntp, ntpdate or
what ever.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ralf Mardorf
Nov 28, 2012, 1:40:02 PM11/28/12
to
On Wed, 2012-11-28 at 11:48 -0600, green wrote:
In the sentence from me above I've wrtten taht I don't use Windows.
I haven't written that I would get issues when using UTC, but I also
don't get issues, when I'm using local time.
Nobody did explain how the BIOS should save files with German time, if
the clock is set to UTC.
Again, some people have a BIOS and do use it ;). Some people save BIOS
settings to e.g. USB. No Linux, no Windows, it's just the BIOS.
If the clock does use local time, then the time for all BIOS and all
Linux files are ok.
If the clock is set to local time, then the time for the BIOS files is
I haven't written that I would get issues when using UTC, but I also
don't get issues, when I'm using local time.
Nobody did explain how the BIOS should save files with German time, if
the clock is set to UTC.
Again, some people have a BIOS and do use it ;). Some people save BIOS
settings to e.g. USB. No Linux, no Windows, it's just the BIOS.
If the clock does use local time, then the time for all BIOS and all
Linux files are ok.
If the clock is set to local time, then the time for the BIOS files is
wrong, only the files for Linux are ok.
So, what is better?
All files have the wanted, correct time or just Linux files have the
correct time?
Don't mention Windows again and again.
Do you have a BIOS or have you some magic Linux replacement for the
BIOS?
So, what is better?
All files have the wanted, correct time or just Linux files have the
correct time?
Don't mention Windows again and again.
Do you have a BIOS or have you some magic Linux replacement for the
BIOS?
Regards,
Ralf
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1354126362.3152.38.camel@q
Ralf
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ralf Mardorf
Nov 28, 2012, 1:40:02 PM11/28/12
to
On Wed, 2012-11-28 at 19:12 +0100, Ralf Mardorf wrote:
IS NOT SET oops, a typo ;)
> wrong, only the files for Linux are ok.
>
> So, what is better?
>
> All files have the wanted, correct time or just Linux files have the
> correct time?
>
> Don't mention Windows again and again.
>
> Do you have a BIOS or have you some magic Linux replacement for the
> BIOS?
>
> Regards,
> Ralf
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1354126679.3152.39.camel@q
>
> So, what is better?
>
> All files have the wanted, correct time or just Linux files have the
> correct time?
>
> Don't mention Windows again and again.
>
> Do you have a BIOS or have you some magic Linux replacement for the
> BIOS?
>
> Regards,
> Ralf
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Hilco Wijbenga
Nov 28, 2012, 1:50:02 PM11/28/12
to
On 28 November 2012 09:04, Ralf Mardorf <ralf.m...@rocketmail.com> wrote:
> On Wed, 2012-11-28 at 08:45 -0800, unruh wrote:
>> In linux.debian.user, you wrote:
>> > On Wed, 2012-11-28 at 08:44 -0300, Eike Lantzsch wrote:
>> >> Yep. Unfortunately Microsoft never learned in > 25 years that the
>> >> world has more time zones than they might have imagined in DOS-times.
>> >
>> > They did and as I already explained, I want to have the local time for
>> > the BIOS too.
>>
>> Why? Linux is designed to run the system time on UTC and to always
>> interpret the time using /etc/localtime, usually into localtime. All
>> filestamps are raw in UTC but interpreted into localtime. It is just
>> silly to have the rtc/bios clock on localtime, and causes problems and
>> has absolutely no advantages.
>
> If I save BIOS settings as a file and the hwclock is set to UTC, the
> files don't get the German time. The BIOS is the BIOS, it's neither
> Windows, I don't use Windows, but nor the BIOS is Linux, so Linux can't
> "translate" UTC to local time, when I save BIOS settings.
So you spend most of your time in your BIOS? Then you save your
> On Wed, 2012-11-28 at 08:45 -0800, unruh wrote:
>> In linux.debian.user, you wrote:
>> > On Wed, 2012-11-28 at 08:44 -0300, Eike Lantzsch wrote:
>> >> Yep. Unfortunately Microsoft never learned in > 25 years that the
>> >> world has more time zones than they might have imagined in DOS-times.
>> >
>> > They did and as I already explained, I want to have the local time for
>> > the BIOS too.
>>
>> Why? Linux is designed to run the system time on UTC and to always
>> interpret the time using /etc/localtime, usually into localtime. All
>> filestamps are raw in UTC but interpreted into localtime. It is just
>> silly to have the rtc/bios clock on localtime, and causes problems and
>> has absolutely no advantages.
>
> If I save BIOS settings as a file and the hwclock is set to UTC, the
> files don't get the German time. The BIOS is the BIOS, it's neither
> Windows, I don't use Windows, but nor the BIOS is Linux, so Linux can't
> "translate" UTC to local time, when I save BIOS settings.
settings and compare that file to previous settings? And then you go
back and do it again? And again? Is that really how you spend your
time? :-) That seems unlikely. So why do you care?
> Under Linux I never noticed any disadvantage, when the hwclock is set to
> local time. Why should there be issues?
a proper time zone set, your computer will repeat an hour every year.
That might cause problems (if your computer is on during that hour).
But these problems are known so software might work around it. Lots of
people dual boot with Windows (which forces them to use local time) so
you should be okay.
As others have mentioned: UNIX uses UTC. That's the smart thing to do
because it's reliable (independent of time zones and summer/winter
time) and every timestamp is fixed. By using local time you are
swimming against the current but I don't think the current is all that
strong. :-) It just seems to me that doing something that is
suboptimal for the sake of a BIOS' settings file's timestamp is a bit
silly.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ralf Mardorf
Nov 28, 2012, 2:00:02 PM11/28/12
to
I guess there's a language barrier.
Those two files were not saved with Linux and not saved with Windows,
they were saved by the BIOS:
spinymouse@q:~$ ls -l /media/spinymouse/INTENSO/*.CMO
-rw-r--r-- 1 spinymouse spinymouse 304 Oct 22 2011 /media/spinymouse/INTENSO/B22OCT11.CMO
-rw-r--r-- 1 spinymouse spinymouse 304 Sep 30 2011 /media/spinymouse/INTENSO/B30SEP11.CMO
This are the settings of the BIOS.
There is no time shown, but the date depends to the time.
If I would use UTC, how should I ensure that the date would be correct
for Germany? Yes, by the file name, but the date for the files could be
wrong.
If I use local time, the BIOS can save the correct date and it won't
harm Linux. Even if it would cause a wrong time for Linux, I could run
ntpdate and the Linux time would be correct.
So, UTC has got an disadvantage and local time has got no disadvantage.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1354127860.3152.51.camel@q
Those two files were not saved with Linux and not saved with Windows,
they were saved by the BIOS:
spinymouse@q:~$ ls -l /media/spinymouse/INTENSO/*.CMO
-rw-r--r-- 1 spinymouse spinymouse 304 Oct 22 2011 /media/spinymouse/INTENSO/B22OCT11.CMO
-rw-r--r-- 1 spinymouse spinymouse 304 Sep 30 2011 /media/spinymouse/INTENSO/B30SEP11.CMO
This are the settings of the BIOS.
There is no time shown, but the date depends to the time.
If I would use UTC, how should I ensure that the date would be correct
for Germany? Yes, by the file name, but the date for the files could be
wrong.
If I use local time, the BIOS can save the correct date and it won't
harm Linux. Even if it would cause a wrong time for Linux, I could run
ntpdate and the Linux time would be correct.
So, UTC has got an disadvantage and local time has got no disadvantage.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ralf Mardorf
Nov 28, 2012, 2:40:01 PM11/28/12
to
On Wed, 2012-11-28 at 10:40 -0800, Hilco Wijbenga wrote:
> On 28 November 2012 09:04, Ralf Mardorf <ralf.m...@rocketmail.com> wrote:
> > On Wed, 2012-11-28 at 08:45 -0800, unruh wrote:
> >> In linux.debian.user, you wrote:
> >> > On Wed, 2012-11-28 at 08:44 -0300, Eike Lantzsch wrote:
> >> >> Yep. Unfortunately Microsoft never learned in > 25 years that the
> >> >> world has more time zones than they might have imagined in DOS-times.
> >> >
> >> > They did and as I already explained, I want to have the local time for
> >> > the BIOS too.
> >>
> >> Why? Linux is designed to run the system time on UTC and to always
> >> interpret the time using /etc/localtime, usually into localtime. All
> >> filestamps are raw in UTC but interpreted into localtime. It is just
> >> silly to have the rtc/bios clock on localtime, and causes problems and
> >> has absolutely no advantages.
> >
> > If I save BIOS settings as a file and the hwclock is set to UTC, the
> > files don't get the German time. The BIOS is the BIOS, it's neither
> > Windows, I don't use Windows, but nor the BIOS is Linux, so Linux can't
> > "translate" UTC to local time, when I save BIOS settings.
>
> So you spend most of your time in your BIOS? Then you save your
> settings and compare that file to previous settings? And then you go
> back and do it again? And again? Is that really how you spend your
> time? :-) That seems unlikely. So why do you care?
No and I won't explain why this could be important, snce it doesn't
> On 28 November 2012 09:04, Ralf Mardorf <ralf.m...@rocketmail.com> wrote:
> > On Wed, 2012-11-28 at 08:45 -0800, unruh wrote:
> >> In linux.debian.user, you wrote:
> >> > On Wed, 2012-11-28 at 08:44 -0300, Eike Lantzsch wrote:
> >> >> Yep. Unfortunately Microsoft never learned in > 25 years that the
> >> >> world has more time zones than they might have imagined in DOS-times.
> >> >
> >> > They did and as I already explained, I want to have the local time for
> >> > the BIOS too.
> >>
> >> Why? Linux is designed to run the system time on UTC and to always
> >> interpret the time using /etc/localtime, usually into localtime. All
> >> filestamps are raw in UTC but interpreted into localtime. It is just
> >> silly to have the rtc/bios clock on localtime, and causes problems and
> >> has absolutely no advantages.
> >
> > If I save BIOS settings as a file and the hwclock is set to UTC, the
> > files don't get the German time. The BIOS is the BIOS, it's neither
> > Windows, I don't use Windows, but nor the BIOS is Linux, so Linux can't
> > "translate" UTC to local time, when I save BIOS settings.
>
> So you spend most of your time in your BIOS? Then you save your
> settings and compare that file to previous settings? And then you go
> back and do it again? And again? Is that really how you spend your
> time? :-) That seems unlikely. So why do you care?
matter. But try to imagine that it might be important and that companies
take care about this, among others, Microsoft does take care. And I
still don't use Microsoft, but have other reasons to use local time.
> > Under Linux I never noticed any disadvantage, when the hwclock is set to
> > local time. Why should there be issues?
>
> By and large, I don't think you will see any issues.
using local time.
I don't say that UTC always is an disadvantage, I just try to say, that
for some usages it is an disadvantage.
Nobody does explain for what usage UTC is an advantage.
> Assuming you have
> a proper time zone set, your computer will repeat an hour every year.
> That might cause problems (if your computer is on during that hour).
> But these problems are known so software might work around it. Lots of
> people dual boot with Windows (which forces them to use local time) so
> you should be okay.
using local time.
> As others have mentioned: UNIX uses UTC.
give an explanation, why this is less good.
But somebody already blamed Microsoft as idiots. They are idiots, but
not regarding to this issue.
> That's the smart thing to do
> because it's reliable (independent of time zones and summer/winter
> time) and every timestamp is fixed. By using local time you are
> swimming against the current but I don't think the current is all that
> strong. :-) It just seems to me that doing something that is
> suboptimal for the sake of a BIOS' settings file's timestamp is a bit
> silly.
there's no Windows on my machine (excepted of XP on VBox). 9 years
without an issue using local time, but the advantage that the BIOS can
add the correct timestamp too.
So what is the advantage of using UTC? Until now I only see an
disadvantage using UTC.
Errare humanum est, sed in errare perseverare diabolicum ;).
If I'm mistaken and there should really be an disadvantage using local
time, can somebody please explain it? If not, why cherish something that
has the disadvantage I mentioned? And why always talking about
Microsoft? This is a Linux list. The BIOS is needed by Linux too.
Regards,
Ralf
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andrei POPESCU
Nov 28, 2012, 3:30:02 PM11/28/12
to
On Mi, 28 nov 12, 14:09:42, Ralf Mardorf wrote:
>
> The Linux has to know if the hwclock does use UTC or not and then it
> will set up the clock, when running a Linux to the correct time for your
> timezone. IOW you only have to inform what time hwclock does use.
Yes.
>
> The Linux has to know if the hwclock does use UTC or not and then it
> will set up the clock, when running a Linux to the correct time for your
> timezone. IOW you only have to inform what time hwclock does use.
> I'm living in Germany, if my hwclock would use UTC time, then saving
> e.g. BIOS settings, would add a wrong time to the files. So I can't see
> an advantage in using UTC. I'm using local time for the hwclock.
moved to a different location you have to change both the BIOS clock and
the timezone configuration, whereas if the hardware clock is set to UTC
you only have to change the timezone configuration.
I can't think of any other issue (assuming correct configuration).
Eike Lantzsch
Nov 28, 2012, 4:10:01 PM11/28/12
to
On Wednesday 28 November 2012 10:09:42 Ralf Mardorf wrote:
> On Wed, 2012-11-28 at 15:55 +0530, J. B wrote:
> > Hello list,
> >
> > My box is configured to the local time zone from beginning, both hwclock
> > and system time. But linux always favor hwclock to UTC. What is the
> > advantage of doing that ?
Your hwclock stays put and daylight saving and latitude is managed by tzdata to show local time. File time-stamps are set to local time, however.
Please correct me if I'm wrong.
ref:
http://www.tldp.org/HOWTO/TimePrecision-HOWTO/set.html
The document distinguishes between a Linux-only-system and a double-boot-system with MS Windows.
In the case of double boot you should set hwclock to local time, as mentioned in the document, or follow the advice by Andrei Popescu and set hwclock to UTC and let WIndows also show UTC. That is useful for radio amateurs who log their activity in UTC anyway.
> >
> > If I need my hwclock to UTC then what should be the right way to do that
> > ? I have followed "dpkg-reconfigure tzdata" and found it has changed the
> > local time to UTC too. Confused .....
Well, J.B. you did something wrong then.
Please show us exactly which steps you did - command by command. Did you set hwclock in the BIOS and then rebooted or did you use "hwclock -u"?
Please show us:
"hwclock -r"
"date"
"date -u"
contents of:
/etc/adjtime
/etc/default/hwclock
/etc/timezone
Then we might be able to find out where the snag lies.
>
> The Linux has to know if the hwclock does use UTC or not and then it
> will set up the clock, when running a Linux to the correct time for your
> timezone. IOW you only have to inform what time hwclock does use.
hwclock --utc
>
> I'm living in Germany, if my hwclock would use UTC time, then saving
> e.g. BIOS settings, would add a wrong time to the files. So I can't see
> an advantage in using UTC. I'm using local time for the hwclock.
Well, Ralf, that wasn't exactly the setting of the OP or was it?
Why do you think that the file creation time is set to UTC and not local time unless your system time is UTC too?
File timestamps are set according to system time - always, or did I miss something?
Here:
hwclock --systohc --utc
username@hostname:~$ touch filetimetest
username@hostname:~$ ls -la |grep timetest
-rw-r--r-- 1 user group 0 Nov 28 11:42 filetimetest
username@hostname:~$ date -u
Wed Nov 28 14:43:01 UTC 2012
username@hostname:~$ date
Wed Nov 28 11:43:03 PYST 2012
Kind regards
Eike
Ralf Mardorf
Nov 28, 2012, 4:10:01 PM11/28/12
to
On Wed, 2012-11-28 at 22:26 +0200, Andrei POPESCU wrote:
> On Mi, 28 nov 12, 14:09:42, Ralf Mardorf wrote:
> >
> > The Linux has to know if the hwclock does use UTC or not and then it
> > will set up the clock, when running a Linux to the correct time for your
> > timezone. IOW you only have to inform what time hwclock does use.
>
> Yes.
>
> > I'm living in Germany, if my hwclock would use UTC time, then saving
> > e.g. BIOS settings, would add a wrong time to the files. So I can't see
> > an advantage in using UTC. I'm using local time for the hwclock.
>
> Probably not a major problem, but assuming the computer is physically
> moved to a different location you have to change both the BIOS clock and
> the timezone configuration, whereas if the hardware clock is set to UTC
> you only have to change the timezone configuration.
>
> I can't think of any other issue (assuming correct configuration).
More likely that I don't carry round my tower through different
> On Mi, 28 nov 12, 14:09:42, Ralf Mardorf wrote:
> >
> > The Linux has to know if the hwclock does use UTC or not and then it
> > will set up the clock, when running a Linux to the correct time for your
> > timezone. IOW you only have to inform what time hwclock does use.
>
> Yes.
>
> > I'm living in Germany, if my hwclock would use UTC time, then saving
> > e.g. BIOS settings, would add a wrong time to the files. So I can't see
> > an advantage in using UTC. I'm using local time for the hwclock.
>
> Probably not a major problem, but assuming the computer is physically
> moved to a different location you have to change both the BIOS clock and
> the timezone configuration, whereas if the hardware clock is set to UTC
> you only have to change the timezone configuration.
>
> I can't think of any other issue (assuming correct configuration).
timezones, then saving BIOS settings. It would be interesting to know,
if laptop users who e.g. often fly from one continent to another, tend
to keep their home country time, or if they tend to switch the local
entry. I guess I would keep the config, even when using UTC and as a
watch I would use a world clock application.
Regards,
Ralf
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Gary Dale
Nov 28, 2012, 4:10:01 PM11/28/12
to
On 28/11/12 03:26 PM, Andrei POPESCU wrote:
> On Mi, 28 nov 12, 14:09:42, Ralf Mardorf wrote:
>> The Linux has to know if the hwclock does use UTC or not and then it
>> will set up the clock, when running a Linux to the correct time for your
>> timezone. IOW you only have to inform what time hwclock does use.
> Yes.
>
>> I'm living in Germany, if my hwclock would use UTC time, then saving
>> e.g. BIOS settings, would add a wrong time to the files. So I can't see
>> an advantage in using UTC. I'm using local time for the hwclock.
> Probably not a major problem, but assuming the computer is physically
> moved to a different location you have to change both the BIOS clock and
> the timezone configuration, whereas if the hardware clock is set to UTC
> you only have to change the timezone configuration.
>
> I can't think of any other issue (assuming correct configuration).
>
> Kind regards,
> Andrei
I note that BIOS clocks don't store or even recognize the time zone.
> On Mi, 28 nov 12, 14:09:42, Ralf Mardorf wrote:
>> The Linux has to know if the hwclock does use UTC or not and then it
>> will set up the clock, when running a Linux to the correct time for your
>> timezone. IOW you only have to inform what time hwclock does use.
> Yes.
>
>> I'm living in Germany, if my hwclock would use UTC time, then saving
>> e.g. BIOS settings, would add a wrong time to the files. So I can't see
>> an advantage in using UTC. I'm using local time for the hwclock.
> Probably not a major problem, but assuming the computer is physically
> moved to a different location you have to change both the BIOS clock and
> the timezone configuration, whereas if the hardware clock is set to UTC
> you only have to change the timezone configuration.
>
> I can't think of any other issue (assuming correct configuration).
>
> Kind regards,
> Andrei
Linux takes the time from the BIOS clock then interprets it using the
machine's clock and timezone settings. When the computer is shut down,
Linux updates the BIOS clock. In between, it ignores it.
If you have a lap top and fly from one time zone to another, you can set
your computer to display local times by changing the time zone setting.
This will update the display of times but won't impact how they are
stored, which is always in unix time. If you shut down your laptop, it's
BIOS clock will be updated with the new local time.
When you restart the laptop, it will use the current BIOS time as a
starting point. This can be changed by chrony or ntp, if you are running
them.
In short, there is little advantage to using one clock setting over the
other. UTC is generally more logical and standard but Windows uses local
time (figures), so dual booting will give you headaches (just try
running a live CD on a Windows computer - the times will be messed up.
Linux respects and correctly handles whichever time setting you use but
unless you are running Windows, there is no reason not to use UTC.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Gary Dale
Nov 28, 2012, 4:30:02 PM11/28/12
to
File stamps are unix time. This is the number of seconds since
midnight, January 1, 1970 (UTC) not counting leap seconds. This is
also how the Linux clock tracks time so that no calculations are
required when saving the current time as a file's time stamp. The
time displayed on your computer is simply a human-readable
interpretation of the internal clock based on your time zone
settings.
The only way that the timezone and BIOS clock settings come into play is if they are wrong! If you tell the computer you're in the wrong time zone, it will believe you and act accordingly. However, anyone running ntp or chrony has to work to get the wrong time stamps on files.
The only way that the timezone and BIOS clock settings come into play is if they are wrong! If you tell the computer you're in the wrong time zone, it will believe you and act accordingly. However, anyone running ntp or chrony has to work to get the wrong time stamps on files.
Eike Lantzsch
Nov 28, 2012, 5:40:02 PM11/28/12
to
That refers to me, but I didn't say "Idiots", I said "retards" and that is not because of their decision to use hwclock set to localtime but because they do ignore many timezones and do create problems for users in countries which do not appear in their list of timezones. I consider it retarded to ignore the needs of one's customers not only for years, but for decades
But maybe purchasing such goods is even more retarded.
Now back to Unix:.
>
> > That's the smart thing to do
Oops this statement appears now very much out of context but looks cute.
Take this as an example for HOW NOT TO CITE.
> >
> > because it's reliable (independent of time zones and summer/winter
> > time) and every timestamp is fixed. By using local time you are
> > swimming against the current but I don't think the current is all that
> > strong. :-) It just seems to me that doing something that is
> > suboptimal for the sake of a BIOS' settings file's timestamp is a bit
> > silly.
>
> I don't have an disadvantage, I'm using Linux since November 2003,
> there's no Windows on my machine (excepted of XP on VBox). 9 years
> without an issue using local time, but the advantage that the BIOS can
> add the correct timestamp too.
You may do that as you please and if the timestamp on files saved from BIOS is so important to you it is certainly a valid reason to do so.
> So what is the advantage of using UTC? Until now I only see an
> disadvantage using UTC.
The advantage is that because UNIX is designed that way with worldwide networking in mind it is usually (but as you validly pointed out, not always) best to set up the system according to design criteria.
E.g. it becomes sometimes interesting when e-mails are exchanged with mail clients on different OS. Or think of banking transactions or stock exchange transactions.
Mind you that timestamps are not saved as date/time but as Unix time numbers according to the Unix epoch. The Unix time number is then interpreted by the system as date / time according to /etc/localtime.
Even under Unix there are different standards for doing this and of course there are also problems.
see: https://en.wikipedia.org/wiki/Unix_time
If there is a discrepancy between files created by BIOS and those created by the Unix system then it is obvious that the BIOS in question does not use Unix time numbers.
It could have been programmed that way or not. I wonder if there are BIOSes which use the Unix time number? SGI, SUN, experience anybody?
In the 1980s many of our customers (WANG) used local time on the hardware clock. That became an issue as soon as the systems started to be networked / interconnected with IBM SNA and later WANGOFFICE.
The problems which can occur if the hwclock is not set to UTC and the local time calculated according to timezone and the country's daylight saving arrangement is that files created during the shift from daylightsaving to normal time or back you might have diverse files with timestamps close to each other while in reality the files were created more than an hour apart.
This can be the case in the same way if you save files from BIOS during the timeshift, provided your hwclock is set by your system after you rebooted. Using ntp of course.
I admit that this problem might be purely academic as long as you have only one or a few systems to maintain but as soon as the systems are many and diverse as to operating systems, there are headaches preprogrammed.
Been there - done that.
>
> Errare humanum est, sed in errare perseverare diabolicum ;).
>
> If I'm mistaken and there should really be an disadvantage using local
> time, can somebody please explain it? If not, why cherish something that
> has the disadvantage I mentioned? And why always talking about
> Microsoft? This is a Linux list. The BIOS is needed by Linux too.
Because we aproached this from a more general standpoint and the case which you mentioned is a very special case. As I said: both standpoints are valid.
You state a case in which it is not helpful to set hwclock to UTC and we said that *in general* on Unix-like systems it is better to set hwclock to UTC.
Both statements do not exclude each other.
>
> Regards,
> Ralf
Yes, and best regards too
Eike
Ralf Mardorf
Nov 28, 2012, 6:10:02 PM11/28/12
to
On Wed, 2012-11-28 at 19:31 -0300, Eike Lantzsch wrote:
> Or think of banking transactions or stock exchange transactions.
I guess something like this really is an issue, but I also suspect that
> Or think of banking transactions or stock exchange transactions.
this anyway will be handled by special software.
Thank you for the explanation,
Ralf
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1354142641.3152.131.camel@q
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ralf Mardorf
Nov 28, 2012, 6:20:03 PM11/28/12
to
On Wed, 2012-11-28 at 19:31 -0300, Eike Lantzsch wrote: [snip]
spinymouse@q:~$ ls -l /media/spinymouse/INTENSO/
total 32
-rw-r--r-- 1 spinymouse spinymouse 304 Oct 22 2011 B22OCT11.CMO
-rw-r--r-- 1 spinymouse spinymouse 304 Sep 30 2011 B30SEP11.CMO
-rw-r--r-- 1 spinymouse spinymouse 15644 Nov 10 2011 Hakle-Geld-zurück.odt
-rw-r--r-- 1 spinymouse spinymouse 33 Oct 13 23:11 Ubuntu_Studio_USB_stick_test.txt
-rw-r--r-- 1 spinymouse spinymouse 30 Oct 13 23:11 Ubuntu_Studio_USB_stick_test.txt~
Nautilus does show time and date for all files of the FAT formatted USB
stick. I'm not sure if time and date will differ, if I switch local and
I won't test it now. Only the first two files are from the BIOS, the
other 3 files are from Linux installs.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1354143283.3152.136.camel@q
spinymouse@q:~$ ls -l /media/spinymouse/INTENSO/
total 32
-rw-r--r-- 1 spinymouse spinymouse 304 Oct 22 2011 B22OCT11.CMO
-rw-r--r-- 1 spinymouse spinymouse 304 Sep 30 2011 B30SEP11.CMO
-rw-r--r-- 1 spinymouse spinymouse 15644 Nov 10 2011 Hakle-Geld-zurück.odt
-rw-r--r-- 1 spinymouse spinymouse 33 Oct 13 23:11 Ubuntu_Studio_USB_stick_test.txt
-rw-r--r-- 1 spinymouse spinymouse 30 Oct 13 23:11 Ubuntu_Studio_USB_stick_test.txt~
Nautilus does show time and date for all files of the FAT formatted USB
stick. I'm not sure if time and date will differ, if I switch local and
I won't test it now. Only the first two files are from the BIOS, the
other 3 files are from Linux installs.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ralf Mardorf
Nov 28, 2012, 9:40:01 PM11/28/12
to
On Wed, 2012-11-28 at 16:01 -0800, unruh wrote:
> In linux.debian.user, you wrote:
> >
> > Exactly, there are no issues when using Linux with the hardware clock
> > using local time.
>
> Yes, there are. If the clock is on localtime, when Linux boots up it
> In linux.debian.user, you wrote:
> >
> > Exactly, there are no issues when using Linux with the hardware clock
> > using local time.
>
> assumes that the bios clock really is on local time-- and if since you
> last shut it down, daylight saving time change has occured, it assumes
> that yo uhave adjusted your bios clock to the correct daylight saving
> time. Ie, YOU have to make sure that your bios clock is always on the
> correct time including all DST changes. Under UTC the bios clock never
> changes for DST. Linux uses /etc/localtime to display the DST corrected
> time, but the bios clock does NOT have to be adjusted with DST occurs.
That's not true, after running ntpdate everything is ok.
> >
> > I don't say that UTC always is an disadvantage, I just try to say, that
> > for some usages it is an disadvantage.
>
So the BIOS does transform the UTC time to local time too? It doesn't.
>
> >
> > Nobody does explain for what usage UTC is an advantage.
> >
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1354155744.2393.4.camel@q
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
John Hasler
Nov 28, 2012, 10:30:01 PM11/28/12
to
Ralf Mardorf writes:
> That's not true, after running ntpdate everything is ok.
Except for anything that happened before ntpdate ran, such as writing
> That's not true, after running ntpdate everything is ok.
logs. And if ntpdate never runs because it can't reach a server you're
an hour off. There are also services that become quite distressed if
the clock jumps back an hour.
--
John Hasler
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ralf Mardorf
Nov 28, 2012, 11:00:02 PM11/28/12
to
On Wed, 2012-11-28 at 21:22 -0600, John Hasler wrote:
> There are also services that become quite distressed if the clock
> jumps back an hour.
OIC
> There are also services that become quite distressed if the clock
> jumps back an hour.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Roger Leigh
Dec 1, 2012, 9:30:02 AM12/1/12
to
On Wed, Nov 28, 2012 at 03:55:16PM +0530, J. B wrote:
>
>
> My box is configured to the local time zone from beginning, both hwclock and
> system time.
Firstly, to clarify, there are two clocks:
> system time.
- hardware clock (UTC or local)
- system clock (UTC)
The system clock is *always* UTC. Even if you, the user, are using
a local timezone, the local time is calculated based upon the time
in the UTC system clock. Given that Linux is a multi-user system,
you can have several users, each in a separate timezone. All see
file timestamps and other dates in their respective timezones,
though all of them are stored in UTC internally. It's completely
transparent to the user.
> But linux always favor hwclock to UTC. What is the advantage of doing that ?
take a look at
- /lib/udev/hwclock-set
- /etc/init.d/hwclock.sh
- hwclock(8)
At boot, we have the following sequence:
- UTC hardware clock
+ system clock (UTC) set from hardware clock (UTC) by kernel
+ no further action
- LOCAL hardware clock
+ system clock (LOCAL) set from hardware clock (LOCAL) by kernel
+ system clock adjusted from LOCAL to UTC by hwclock-set or hwclock.sh
Since the system clock is UTC but is actually in local time for part
of the boot, this means that until it's corrected later in the boot,
it's incorrect to start with, and this can make the clock run backwards
at the time of adjustment, and this screws up timestamps prior to the
correction. Having the hardware clock in UTC means that the clock is
correct (modulo any NTP adjustment) from the moment the kernel starts
executing.
The other issue with LOCAL is that if you dual boot, both operating
systems may change the hardware clock on daylight savings changes,
making the clock become inaccurate. Since the clock doesn't know
if it's been adjusted, there's no way to know that the adjustment
should be applied (or not). Even a single boot system doesn't have
a way to record whether or not the adjustment is made--there are
corner cases if the clock gets adjusted where it may be applied
twice (or not at all). Storing the time in UTC solves all these
issues, since it never requires any daylight savings adjustment.
> If I need my hwclock to UTC then what should be the right way to do that ?
> I have followed "dpkg-reconfigure tzdata" and found it has changed the local time to
> UTC too. Confused .....
with "date --set="newdate" if it's wrong). Then run
hwclock --utc --systohc
to set the hardware clock from the system clock in UTC. Look at
/etc/adjtime and you should see UTC on the third line. Use --local
in place of --utc, and it switches it back to LOCAL. I'd definitely
recommend using UTC though.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Roger Leigh
Dec 1, 2012, 4:50:01 PM12/1/12
to
On Sat, Dec 01, 2012 at 02:19:50PM +0000, Roger Leigh wrote:
> On Wed, Nov 28, 2012 at 03:55:16PM +0530, J. B wrote:
> >
> > If I need my hwclock to UTC then what should be the right way to do that ?
> > I have followed "dpkg-reconfigure tzdata" and found it has changed the local time to
> > UTC too. Confused .....
>
> Just make sure that the date is set correctly (run "date" and set it
> with "date --set="newdate" if it's wrong). Then run
> hwclock --utc --systohc
> to set the hardware clock from the system clock in UTC. Look at
> /etc/adjtime and you should see UTC on the third line. Use --local
> in place of --utc, and it switches it back to LOCAL. I'd definitely
> recommend using UTC though.
Just to clear up any confusion regarding your question:
> On Wed, Nov 28, 2012 at 03:55:16PM +0530, J. B wrote:
> >
> > If I need my hwclock to UTC then what should be the right way to do that ?
> > I have followed "dpkg-reconfigure tzdata" and found it has changed the local time to
> > UTC too. Confused .....
>
> Just make sure that the date is set correctly (run "date" and set it
> with "date --set="newdate" if it's wrong). Then run
> hwclock --utc --systohc
> to set the hardware clock from the system clock in UTC. Look at
> /etc/adjtime and you should see UTC on the third line. Use --local
> in place of --utc, and it switches it back to LOCAL. I'd definitely
> recommend using UTC though.
The date command has a --utc option. Without it, date will
display (or with --set, will set) the system clock in your local
timezone. But the system clock is still always in UTC; it's
just transparently converting it to (or from, if setting) your
timezone unless you specify the --utc option, in which case no
conversion will take place.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
J. B
Dec 3, 2012, 1:50:01 AM12/3/12
to
On Sat, 1 Dec 2012 14:19:50 +0000
Roger Leigh <rle...@codelibre.net> wrote:
<snip>
> Regards,
> Roger
>
I have saved your full email as a future reference and it will be a good
reference for those who are suffering with the same confusion as mine, before
reading your email. Many many thanks for your contribution.
I have checked my /etc/adjtime and found
[.....]
-0.408399 1354206971 0.000000
1354206971
UTC
[......]
So my system is following the UTC :-)
And also set the H/W clock to UTC with "hwclock --utc --systohc"
still my H/W clock shows local timezone !!!
How can I keep the H/W to UTC then and how can I apply different
timezone to different login user ? say someone use german and another different
login user use uk timezone. dpkg-reconfigure sure change the H/W timezone to UTC, but
also changes local.
Once again thanks for your excellent clarifications.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20121203121...@shiva.selfip.org
Roger Leigh <rle...@codelibre.net> wrote:
<snip>
> Just make sure that the date is set correctly (run "date" and set it
> with "date --set="newdate" if it's wrong). Then run
> hwclock --utc --systohc
> to set the hardware clock from the system clock in UTC. Look at
> /etc/adjtime and you should see UTC on the third line. Use --local
> in place of --utc, and it switches it back to LOCAL. I'd definitely
> recommend using UTC though.
>
>
</snip>
> with "date --set="newdate" if it's wrong). Then run
> hwclock --utc --systohc
> to set the hardware clock from the system clock in UTC. Look at
> /etc/adjtime and you should see UTC on the third line. Use --local
> in place of --utc, and it switches it back to LOCAL. I'd definitely
> recommend using UTC though.
>
>
> Regards,
> Roger
>
I have saved your full email as a future reference and it will be a good
reference for those who are suffering with the same confusion as mine, before
reading your email. Many many thanks for your contribution.
I have checked my /etc/adjtime and found
[.....]
-0.408399 1354206971 0.000000
1354206971
UTC
[......]
So my system is following the UTC :-)
And also set the H/W clock to UTC with "hwclock --utc --systohc"
still my H/W clock shows local timezone !!!
How can I keep the H/W to UTC then and how can I apply different
timezone to different login user ? say someone use german and another different
login user use uk timezone. dpkg-reconfigure sure change the H/W timezone to UTC, but
also changes local.
Once again thanks for your excellent clarifications.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bob Proulx
Dec 3, 2012, 4:20:02 AM12/3/12
to
J. B wrote:
> And also set the H/W clock to UTC with "hwclock --utc --systohc"
>
> still my H/W clock shows local timezone !!!
What commands are you using to determine that this is the case? If
> And also set the H/W clock to UTC with "hwclock --utc --systohc"
>
> still my H/W clock shows local timezone !!!
you have done the suggestions above then your clock should be in UTC.
> How can I keep the H/W to UTC then and how can I apply different
> timezone to different login user ? say someone use german and
> another different login user use uk timezone. dpkg-reconfigure sure
> change the H/W timezone to UTC, but also changes local.
Every user may have a unique timezone by setting a unique TZ variable
in their environment.
You can set it to be a named timezone like this:
$ TZ=America/Denver date -R
Mon, 03 Dec 2012 01:55:59 -0700
$ TZ=Asia/Kolkata date -R
Mon, 03 Dec 2012 14:40:10 +0530
To set the TZ variable put the following in the user ~/.bashrc or
equivalent file. Use whatever is proper for your desired timezone.
export TZ=Europe/Berlin
See the GNU libc documentation for details:
http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html
In combination with GNU date this can even be used to convert times
from one timezone to another. This example converts from Paris time
to New York time.
$ TZ="America/New_York" date -R --date='TZ="Europe/Paris" 2004-10-31 06:30'
Sun, 31 Oct 2004 01:30:00 -0400
Bob
Roger Leigh
Dec 3, 2012, 4:50:02 AM12/3/12
to
On Mon, Dec 03, 2012 at 12:10:06PM +0530, J. B wrote:
> I have checked my /etc/adjtime and found
>
> [.....]
> -0.408399 1354206971 0.000000
> 1354206971
> UTC
> [......]
>
> So my system is following the UTC :-)
> And also set the H/W clock to UTC with "hwclock --utc --systohc"
This all looks good.
> I have checked my /etc/adjtime and found
>
> [.....]
> -0.408399 1354206971 0.000000
> 1354206971
> UTC
> [......]
>
> So my system is following the UTC :-)
> And also set the H/W clock to UTC with "hwclock --utc --systohc"
> still my H/W clock shows local timezone !!!
"hwclock --show" will always show the clock in local time,
irrespective of whether it is UTC or LOCAL in the hardware
clock itself.
# hwclock --show
Mon 03 Dec 2012 10:45:33 CET -0.903079 seconds
# TZ=UTC hwclock --show
Mon 03 Dec 2012 09:45:40 UTC -0.988834 seconds
> How can I keep the H/W to UTC then and how can I apply different
> timezone to different login user ? say someone use german and another different
> login user use uk timezone. dpkg-reconfigure sure change the H/W timezone to UTC, but
> also changes local.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20121203094...@codelibre.net
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
J. B
Dec 3, 2012, 7:00:02 AM12/3/12
to
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Urs Thuermann
Dec 3, 2012, 1:40:02 PM12/3/12
to
"J. B" <baks...@gmail.com> writes:
> My box is configured to the local time zone from beginning, both
> hwclock and system time. But linux always favor hwclock to
> My box is configured to the local time zone from beginning, both
> UTC. What is the advantage of doing that ?
Although time, timezones and clock setting are quite a simple topic it
seems to be major source of confusion for many people and many systems
are mis-configured, as can seen in this thread and as can be often
seen in E-mail time stamps.
I jumped into this thread somewhat late and wanted to write a couple
of sentences, but now this has become a little bit longer than
intended.
First, to reduce confusion, it is helpful to use good terminology and
to know what the meaning of used terms is.
1. Local time and UTC.
I strongly dislike the term "local time". There is no such thing
as a local time or different local times in different locations (on
earth). There is only one global time. What differs locally is
only the /represantation/ of the time. Nevertheless, I also
sometimes use "local time" to mean "local time representation".
Also, UTC is only /one/ possible representation for times. It is
special in that is "universal", i.e. it is used independent of
location and doesn't have weird things like daylight saving times.
Both, UTC and local time representation, express time as year,
month, day, hour, minute, second, and (hopefully) timezone
indicator.
2. System clock and system time.
The system clock is a software clock driven by the Linux kernel and
it defines the system time. The system clock uses yet another time
representation. Although seemingly everybody states that Linux and
Unix systems run their system clock in UTC, this is IMO not quite
correct. The system time, time stamps in Unix file systems, and
time stamps exchanged between the Linux kernel and user space
programs are representated as a POSIX time_t (or struct timeval or
struct timespec). This representation is only an integer number
counting the seconds since the POSIX epoch (ignoring leap seconds).
The timeval and timespec representation additionally give the
microseconds and nanoseconds, respectively. The POSIX epoch is a
fixed point in time, usually given in UTC time representation and
it is January 1, 1970 0:00:00 UTC. The representation as a simple
integer has several advantages:
* It's very simple to advance the clock by one second. No need to
carry to the next unit after 60 seconds, 60 minutes, 24 hours,
and so on.
* It's very simple to calculate the difference between two times.
* It's independent of local time representation and daylight saving
rules. It doesn't jump forth and back.
When people say "The Linux kernel system time is always in UTC",
what the really mean is that the kernel keeps a time representation
that doesn't depend on any local timezone definitions, doesn't jump
for daylight saving times and is based on a certain point in time
(the epoch) which is usually expressed in UTC (although you could
equally well define the epoch as "December 31, 1969 19:00:00
Eastern Standard Time" because that is the /same/ time as
1970-01-01 0:00:00 UTC).
You can get the current kernel system time with the gettimeofday(2)
or clock_gettime(2) system calls, or print it like this
$ date +%s
1354558752
$ perl -e 'print time,"\n"'
1354558754
I think it's important to understand that you don't set the system
clock to one time or another, you don't set it to "local time" nor
to UTC. You set it to "the current time" (or have it synchronized
to "the current time" using NTP), since there is only one global
time. The representation used by the system clock is POSIX struct
timespec and nothing else.
3. Hardware clock (aka. CMOS clock, BIOS clock or real time clock (RTC)).
This is a clock that ticks independently from any operating system
and even keeps running when the computer is turned off. This clock
represents its time as year-month-day-weekday-hour-minute-second so
it can be set to any local time representation or to UTC.
Unfortunately, it doesn't have information which representation it
is set to nor if it currently is set to daylight saving time or
not. Without this information, you have to guess the meaning of
the time you read from the hardware clock. Therefore, it's best
best to use UTC for this clock since that never has be adjusted for
daylight saving time. Otherwise, in multi-boot system each OS may
adjust thue RTC by one hour resulting in wrong RTC time.
This clock is normally not used in your Linux system, except when
booting the system. Early in the boot process the time is read
from the hardware clock, its time representation is
interpreted/guess (hopefully correct), the POSIX time_t calculated
and the system time set from this. After that, you can read and
set the hardware clock using hwclock(8), but it's not used for
other purposes.
Having the kernel system time represented as a POSIX time_t doesn't
mean the user has to deal with such time representations or with UTC
time representation. There are library routines that, given a local
timezone description, can convert from your selected local time
representation to POSIX time_t and vice versa (localtime(3) and
mktime(3)). In fact, there's not only one such local timezone
description, but there are many and each user[1] can choose which one
to use. The default timezone is specified in /etc/localtime but you
can specify any other timezone using the TZ environment variable (my
default timezone is Europe/Berlin):
$ date
Mon Dec 3 19:19:20 CET 2012
$ TZ=UTC date
Mon Dec 3 18:19:23 UTC 2012
$ TZ=America/Los_Angeles date
Mon Dec 3 10:19:28 PST 2012
$ TZ=America/Detroit date
Mon Dec 3 13:19:32 EST 2012
$ TZ=Asia/Tokyo date
Tue Dec 4 03:19:36 JST 2012
You can also print the date for any time other than the current time
using date's -d option:
$ # The POSIX epoch, expressed in Europe/Berlin timezone
$ date -d@0
Thu Jan 1 01:00:00 CET 1970
$ # One hour later
$ date -d@3600
Thu Jan 1 02:00:00 CET 1970
$ # The epoch expressed in UTC and Los Angeles time
$ TZ=UTC date -d@0
Thu Jan 1 00:00:00 UTC 1970
$ TZ=America/Los_Angeles date -d@0
Wed Dec 31 16:00:00 PST 1969
Using GNU date you can also easily convert any time representation
into a POSIX time_t, i.e. the kernels time representation for that
time:
$ date -d"1967-01-31 17:27" +%s
-92043180
$ TZ=UTC date -d"1967-01-31 16:27" +%s
-92043180
$ # The time that many people celebrated as the begin of a new millenium
$ TZ=America/New_York date -d"2000-01-01 0:00:00" +%s
946702800
Almost all other tools that deal with times, also respect the default
timezone and the TZ environment variable:
$ cd /tmp
$ date; touch foo
Mon Dec 3 19:21:09 CET 2012
$ ls -l --time-style=full-iso foo
-rw-r--r-- 1 urs urs 0 2012-12-03 19:21:09.973761852 +0100 foo
$ TZ=UTC ls -l --time-style=full-iso foo
-rw-r--r-- 1 urs urs 0 2012-12-03 18:21:09.973761852 +0000 foo
$ TZ=America/New_York ls -l --time-style=full-iso foo
-rw-r--r-- 1 urs urs 0 2012-12-03 13:21:09.973761852 -0500 foo
$ TZ=Australia/Sydney find foo -printf "%TF %TT %Tz %p\n"
2012-12-04 05:21:09.9737618520 +1100 foo
$ tar cf bar.tar foo
$ tar tvf bar.tar
-rw-r--r-- urs/urs 0 2012-12-03 19:21 foo
$ TZ=Asia/Shanghai tar tvf bar.tar
-rw-r--r-- urs/urs 0 2012-12-04 02:21 foo
$ # Look at the time displayed in the emacs mode line
$ TZ=Asia/Tokyo emacs --eval "(display-time)"
$ TZ=UTC xclock
And of course, you don't need to specify the timezone to use in every
command, but simply set the TZ environment variable for all subsequent
commands (e.g. in your ~/.profile):
$ export TZ=Europe/Berlin
Or set the default timezone for the system using dpkg or zic -l so
that you don't need to set the TZ environment variable.
[1] To be more precise: The environment variable is not set for each
user, you can even give a different value to each process. That
means you can have several terminal windows and/or X11 clocks
and/or whatever-you-like show different times:
$ TZ=Asia/Tokyo xterm &
$ TZ=Asia/Tokyo xclock -title Tokyo &
$ TZ=Europe/Berlin xterm &
$ TZ=Europe/Berlin xclock -title Berlin &
$ TZ=US/Pacific xclock -title "San Francisco" &
Hint: Have a look at /usr/share/zoneinfo to get an idea which timezone
descriptions are available. To see what a timezone description
contains run from your command-line shell
$ zdump -v America/New_York
German readers might want to read
http://www.ibr.cs.tu-bs.de/users/thuerman/time
where I give some more background info on time. It's > 10 years old,
some links are out-of-date and it's still not complete :-)
urs
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Urs Thuermann
Dec 3, 2012, 2:00:02 PM12/3/12
to
Ralf Mardorf <ralf.m...@rocketmail.com> writes:
> If I save BIOS settings as a file and the hwclock is set to UTC, the
> files don't get the German time. The BIOS is the BIOS, it's neither
> Windows, I don't use Windows, but nor the BIOS is Linux, so Linux can't
> "translate" UTC to local time, when I save BIOS settings.
The problem is that you store to a file system that is broken the same
> If I save BIOS settings as a file and the hwclock is set to UTC, the
> files don't get the German time. The BIOS is the BIOS, it's neither
> Windows, I don't use Windows, but nor the BIOS is Linux, so Linux can't
> "translate" UTC to local time, when I save BIOS settings.
way as the hardware clock, i.e. the MSDOS or VFAT file system that has
no way to indicate what timezone the file time stamps should be
interpreted in.
If you access the vfat file system on your floppy/USB stick using
mtools, you can run the mtools commands in the appropriate TZ
environment. mcopy -m from vfat to linux file system
(ext2/3/4,xfs,btrfs,...) will create the destination file with the
correct POSIX time stamp.
urs
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Urs Thuermann
Dec 3, 2012, 2:20:01 PM12/3/12
to
Ralf Mardorf <ralf.m...@rocketmail.com> writes:
> If the clock does use local time, then the time for all BIOS and all
> Linux files are ok.
This is not completely true. If there is change from/to daylight
> If the clock does use local time, then the time for all BIOS and all
> Linux files are ok.
saving time to/from standard time between saving the files using the
BIOS and booting your Linux system the kernel will see wrong time
stamp on VFAT file systems.
When mounting a vfat file system the kernel will interpret the time
stamps in the file system according to the timezone set using
settimeofday(2). This is usually set only once when the system boots
and it is set to current time offset in minutes compared to UTC. If
this doesn't match the offset when the file were originally created on
the vfat file system, time stamps will be interpreted wrong. I see
this often when I copy pictures from my digital camera's SD card.
IMO this is a flaw in the kernel. The kernel should never use the
timezone set with settimeofday(). If should either have a more
sophisticated timezone handling or not use timezones at all.
A couple of years ago I have begun working on a kernel implementation
for full timezone handling and it worked. But it was for linux 2.4
and the code was quite a quick hack.
urs
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Urs Thuermann
Dec 3, 2012, 3:00:02 PM12/3/12
to
Ralf Mardorf <ralf.m...@rocketmail.com> writes:
> spinymouse@q:~$ ls -l /media/spinymouse/INTENSO/
> total 32
> -rw-r--r-- 1 spinymouse spinymouse 304 Oct 22 2011 B22OCT11.CMO
> -rw-r--r-- 1 spinymouse spinymouse 304 Sep 30 2011 B30SEP11.CMO
> -rw-r--r-- 1 spinymouse spinymouse 15644 Nov 10 2011 Hakle-Geld-zurück.odt
> -rw-r--r-- 1 spinymouse spinymouse 33 Oct 13 23:11 Ubuntu_Studio_USB_stick_test.txt
> -rw-r--r-- 1 spinymouse spinymouse 30 Oct 13 23:11 Ubuntu_Studio_USB_stick_test.txt~
>
> Nautilus does show time and date for all files of the FAT formatted USB
> stick. I'm not sure if time and date will differ, if I switch local and
> I won't test it now. Only the first two files are from the BIOS, the
> other 3 files are from Linux installs.
There seems to be another wrong assumption here. Both, ls and
> spinymouse@q:~$ ls -l /media/spinymouse/INTENSO/
> total 32
> -rw-r--r-- 1 spinymouse spinymouse 304 Oct 22 2011 B22OCT11.CMO
> -rw-r--r-- 1 spinymouse spinymouse 304 Sep 30 2011 B30SEP11.CMO
> -rw-r--r-- 1 spinymouse spinymouse 15644 Nov 10 2011 Hakle-Geld-zurück.odt
> -rw-r--r-- 1 spinymouse spinymouse 33 Oct 13 23:11 Ubuntu_Studio_USB_stick_test.txt
> -rw-r--r-- 1 spinymouse spinymouse 30 Oct 13 23:11 Ubuntu_Studio_USB_stick_test.txt~
>
> Nautilus does show time and date for all files of the FAT formatted USB
> stick. I'm not sure if time and date will differ, if I switch local and
> I won't test it now. Only the first two files are from the BIOS, the
> other 3 files are from Linux installs.
nautilus can show the time (not only date) of all files. By default,
ls -l shows the date including the year if the file is older than 6
months, and the date without the year but with time, otherwise.
With GNU ls, you can use --time-style=long-iso to get minutes and
--time-style=full-iso to get the full time stamp including even
seconds and nano seconds for each file.
This has nothing to with the type of file system the file resides on.
The kernel hides the details of file systems, e.g. the time stamp
representation. If offers the same interface for all file systems,
for ext2/3/4, vfat, iso9660, and all other file system types.
In this case, it is stat(2) defined by POSIX, which gives the file
time stamp as a POSIX time_t, i.e. in seconds. Linux and GNU ls use
an extension that gives the time as POSIX struct timespec, i.e. in
seconds and nano seconds.
urs
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages