On 25/03/2023 10:39, Albretch Mueller wrote:
You can't physically alter a DVD[+|-]R once it is burned ...
Do you customize images to change preferences, e.g. to make OS aware
that hardware clock is set to local time? If you do not than OS almost
certainly assumes that system time is in
hich I use are being kept.
System clock in UTC and time offset rules from time zone database is a
way to reduce maintenance burden. E.g. you do not need to learn how to
synchronize hardware clock and runtime system clock.
You can't physically alter a DVD[+|-]R once it is burned ..
David Wright composed on 2023-03-24 23:20 (UTC-0500):
> BTW I've only really trusted reading or setting the RTC by means of
> the CMOS screens, and treat it as a one-time only process (upon
> acquisition), assuming the coin-cell battery never needs replacing.
Lucky you. I can only dream of going
On Fri 24 Mar 2023 at 19:10:49 (-0400), Stefan Monnier wrote:
> > That works great for the Live OS, but not for the fixed-disk OS. If
> > the Live OS sets the HW clock to local upon shutdown, but the fixed-disk
> > OS expects the HW clock to be UTC, then the fixed-disk OS is wrong
> > every time
e you actually trying to do?
> >
> > What "time zone issues" do you refer to?
>
> I should have pointed out that I always go into exposed mode (use the
> Internet) with a live DVD. My laptop was always 6 hours ahead and now
> that they changed to summer time
On 3/25/23, Max Nikulin wrote:
> - Both Debian and Windows installed on the hard drive ...
Thank you for the steps and the logical elucidations that may
certainly help someone else, but I can't do that "because" all
electronic devices which I use are being kept.
You can't physically alter a
On 25/03/2023 07:07, Albretch Mueller wrote:
I am using right now a DELL laptop which had Windows 11 installed but
I expect that the following should work smoothly enough:
- Hardware clock is in UTC
- Both Debian and Windows installed on the hard drive are configured to
your local time zone
wing to me the same time I can see on
https://www.timeanddate.com/
for my time zone. Devices I use seems to develop a mind of their own ;-)
lbrtchx
> That works great for the Live OS, but not for the fixed-disk OS. If
> the Live OS sets the HW clock to local upon shutdown, but the fixed-disk
> OS expects the HW clock to be UTC, then the fixed-disk OS is wrong
> every time it boots after the Live OS.
AFAIK the Linux kernel is pretty careful
On Fri, Mar 24, 2023 at 05:51:30PM -0400, Stefan Monnier wrote:
> > If your policy choice ends up being "set HW clock to local", then you
> > also have to make sure the correct time zone is set on each operating
> > system, each time it boots. I have no idea how one
> If your policy choice ends up being "set HW clock to local", then you
> also have to make sure the correct time zone is set on each operating
> system, each time it boots. I have no idea how one does that on Debian
> Live, since I've never used Debian Live. So, I
g "set HW clock to local", then you
also have to make sure the correct time zone is set on each operating
system, each time it boots. I have no idea how one does that on Debian
Live, since I've never used Debian Live. So, I can hope for your sake
that Debian Live uses a UTC HW clock.
On 3/24/23, Andy Smith wrote:
> As already pointed out, the hardware clock is used in very limited
> ways and is not the same thing as the system clock, so your result
> is as expected.
> What are you actually trying to do?
>
> What "time zone issues" do you refer to?
; "old" time setting?
As already pointed out, the hardware clock is used in very limited
ways and is not the same thing as the system clock, so your result
is as expected.
What are you actually trying to do?
What "time zone issues" do you refer to?
It is very rare to need to modi
old" time setting?
You're in my time zone, aren't you, so your hardware clock (UTC)
should be five hours ahead of the system clock (CDT). What are
the two times on your system?
# hwclock --verbose
hwclock from util-linux 2.36.1
System Time: 1679611469.019755
Trying to open: /dev/rtc0
U
On 3/23/23, Cindy Sue Causey wrote:
> On 3/23/23, Albretch Mueller wrote:
>> I am using this (yes, visually cr@ppy ;-)) code snippet to set back
>> the time 5 hours. hwclock tells me it worked fine but the terminal
>> windows opened before and after running hwclock still give me the
>> "old"
On 3/23/23, Albretch Mueller wrote:
> I am using this (yes, visually cr@ppy ;-)) code snippet to set back
> the time 5 hours. hwclock tells me it worked fine but the terminal
> windows opened before and after running hwclock still give me the
> "old" time setting?
>
> _HRS_PM=-5
>
> ###
> #
>
> I am using this (yes, visually cr@ppy ;-)) code snippet to set back
> the time 5 hours. hwclock tells me it worked fine but the terminal
> windows opened before and after running hwclock still give me the
> "old" time setting?
The hardware clock is an "external" device which the Linux kernel
I am using this (yes, visually cr@ppy ;-)) code snippet to set back
the time 5 hours. hwclock tells me it worked fine but the terminal
windows opened before and after running hwclock still give me the
"old" time setting?
_HRS_PM=-5
###
#
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Err, whoops.
That wasn't supposed to be encrypted. Not sure how that happened ...
Here we go:
On 02/04/15 00:21, Richard Hector wrote:
On 01/04/15 11:56, Martin Read wrote:
I have a dual-boot Win7/Debian jessie system. Because Windows
doesn't
-BEGIN PGP MESSAGE-
Charset: utf-8
Version: GnuPG v2.0.19 (GNU/Linux)
hQEMA07UmgrFcS2hAQf/dwmi7WfCdgUxzk0BIhdGs9qKWgbRiiVyqxLm2Min3wqF
Xw6mgqsMBh3vQ24CCVmPTF4q2eiy2ZMsGjsFwXm2SJK8WrgsSOKSFtyt77rZHpHx
SExwcy/nXHoSaynm9x3dNwfy2qcrANSmG9dWBiX3HUc1GSw08DVa50D+iqZBmyWH
I have a dual-boot Win7/Debian jessie system. Because Windows doesn't
deal gracefully with handling the hardware time-of-day clock the proper
way (hwclock set to GMT, all TZ handling in software), this means that
the hwclock changes for daylight savings time.
The Debian installation itself
It's an open bug in Debian Jessie:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767040
Until the bug is fixed you can create the file /etc/e2fsck.conf containing
[options]
broken_system_clock=1
Janis
Am 01.04.2015 um 00:56 schrieb Martin Read:
I have a dual-boot Win7/Debian jessie
Ron Leach ronle...@tesco.net wrote:
And London is going to shift from UTC to its local daylight saving time,
British summer Time, BST, sometime in the next week or so.
Pendantically speaking, not really. We were on GMT and are now on BST. UTC
is invariant, and although it just so happens that
On 3/22/2014 11:51 PM, Chris Bannister wrote:
On Fri, Mar 21, 2014 at 11:10:32PM -0400, Jerry Stuckle wrote:
On 3/21/2014 10:08 PM, John Hasler wrote:
Jerry Stuckle writes:
The time needs to be accurate
TAI is accurate. UTC is fudged. The Earth is not a clock. BTW GPS
time ignores leap
Jerry Stuckle writes:
That wouldn't work well. Remember, computers are not the only ones which
use UTC - in fact they are the most imprecise. There are many clocks
around
the world which are synchronized with UTC via radio, i.e. WWV/WWVH in the
United States, CHU in Canada, and other
On 3/22/2014 9:58 AM, Martin G. McCormick wrote:
Jerry Stuckle writes:
That wouldn't work well. Remember, computers are not the only ones which
use UTC - in fact they are the most imprecise. There are many clocks
around
the world which are synchronized with UTC via radio, i.e. WWV/WWVH in the
On Fri, Mar 21, 2014 at 11:10:32PM -0400, Jerry Stuckle wrote:
On 3/21/2014 10:08 PM, John Hasler wrote:
Jerry Stuckle writes:
The time needs to be accurate
TAI is accurate. UTC is fudged. The Earth is not a clock. BTW GPS
time ignores leap seconds. It's what scientists most often use
On 21/03/2014 02:58, Don Armstrong wrote,
very interestingly:
On Thu, 20 Mar 2014, Martin G. McCormick wrote:
That's when I discovered that there are 3
Londons and 3 Chicagos.
That's due to the 35 second difference between TAI and UTC. (The latter
approximates UT1 (earth revolution about its
On Friday 21 March 2014 09:05:37 Ron Leach wrote:
I want to record some radio programs and DST and BST don't start
and stop at the same times.
The way you do this is you start whatever you're using to record
the programs with TZ=Europe/London instead of changing
/etc/localtime
Seems
On 21/03/2014 09:38, Lisi Reisz wrote:
It is standard good practice to keep system time (hardware clock)
at UTC, and desktop time can be local time if you wish.
Hadn't realised any of this, so thank you. If 'system time' and
'desktop time' differ - such as is suggested - what 'timestamp'
Ahoj,
Dňa Fri, 21 Mar 2014 10:57:08 + Ron Leach ronle...@tesco.net
napísal:
On 21/03/2014 09:38, Lisi Reisz wrote:
It is standard good practice to keep system time (hardware
clock) at UTC, and desktop time can be local time if you wish.
Hadn't realised any of this, so thank you.
be. In a lot of
Europe, it will be UTC+1 plus whatever the rules are for where
you live which is why the city names exist. I live about 800
miles or over a thousand kilometers from Chicago, but that is
the city those of us in the US-Central time zone set up as the
localtime file because Chicago keeps
On Fri 21 Mar 2014 at 14:32:33 +0100, Slavko wrote:
There was possible to configure to use UTC or local time as
system time, but this make sense only for multiboot with system(s),
which uses local time only (eg. Windows) and now i cannot find this
setting, because it was taken away from
Ahoj,
Dňa Fri, 21 Mar 2014 16:18:22 + Brian a...@cityscape.co.uk
napísal:
On Fri 21 Mar 2014 at 14:32:33 +0100, Slavko wrote:
There was possible to configure to use UTC or local time as
system time, but this make sense only for multiboot with system(s),
which uses local time only
Le 21/03/2014 17:18, Brian a écrit :
On Fri 21 Mar 2014 at 14:32:33 +0100, Slavko wrote:
There was possible to configure to use UTC or local time as
system time, but this make sense only for multiboot with system(s),
which uses local time only (eg. Windows) and now i cannot find this
On 21/03/2014 02:58, Don Armstrong wrote:
[,,,] due to the 35 second difference between TAI and UTC. (The latter
approximates UT1 (earth revolution about its axis), and the former is
absolute time in SI seconds).
You can read about it in /usr/share/doc/tzdata/README.Debian.
Interesting.
Ron Leach writes:
Interesting. The readme in Wheezy states that TAI includes 'leap
seconds' (the extra seconds added - every so often, a year or so - to
compensate for variations in Earth's rotation) and implies that the
UTC time basis does *not* include the leap seconds. I wonder if that
On 21/03/2014 20:21, John Hasler wrote:
Other way around. TAI does *not* include leap-seconds. It is a
continuous stream of numbered seconds with no gaps and no insertions.
UTC *does* include leap seconds. It is TAI adjusted to stay within one
second of Earth rotation time. Leap seconds
http://en.wikipedia.org/wiki/International_Atomic_Time
http://en.wikipedia.org/wiki/Coordinated_Universal_Time
http://en.wikipedia.org/wiki/Leap_second
More TAI seconds have accumulated since 1972 than have UTC seconds
because the Earth is slowing down and so to keep UTC in sync with the
Earth it
On Friday 21 March 2014 20:02:38 Ron Leach wrote:
The OP might want to keep in mind
that the time he thinks he has set his recording to start may be 35
seconds adrift from when the broadcaster might start. At least, he
might want to check what time he uses, and what time the
broadcaster of
On Friday 21 March 2014 20:43:37 Ron Leach wrote:
And, like the OP, I don't want to miss the start of radio
programmes because the time isn't correct, aligned, or understood.
Never listen to the BBC then.
Lisi
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject
I chose the posix time for Europe/London and the seconds
are in exact step with local time seconds.
Martin
Ron Leach writes:
On 21/03/2014 20:21, John Hasler wrote:
Other way around. TAI does *not* include leap-seconds. It is a
continuous stream of numbered seconds with
On 3/21/2014 5:35 PM, John Hasler wrote:
http://en.wikipedia.org/wiki/International_Atomic_Time
http://en.wikipedia.org/wiki/Coordinated_Universal_Time
http://en.wikipedia.org/wiki/Leap_second
More TAI seconds have accumulated since 1972 than have UTC seconds
because the Earth is slowing down
Jerry Stuckle writes:
The time needs to be accurate
TAI is accurate. UTC is fudged. The Earth is not a clock. BTW GPS
time ignores leap seconds. It's what scientists most often use for
precise timing.
--
John Hasler
jhas...@newsguy.com
Elmwood, WI USA
--
To UNSUBSCRIBE, email to
http://en.wikipedia.org/wiki/Leap_second#Proposal_to_abolish_leap_seconds
--
John Hasler
jhas...@newsguy.com
Elmwood, WI USA
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
On 3/21/2014 10:08 PM, John Hasler wrote:
Jerry Stuckle writes:
The time needs to be accurate
TAI is accurate. UTC is fudged. The Earth is not a clock. BTW GPS
time ignores leap seconds. It's what scientists most often use for
precise timing.
Not all of them. Many use UTC. UTC is
On 3/21/2014 10:14 PM, John Hasler wrote:
http://en.wikipedia.org/wiki/Leap_second#Proposal_to_abolish_leap_seconds
This is hardly the first time this has been proposed. I remember it way
back in the 60's.
There are advantages and disadvantages to it. So far the disadvantages
have
What is the difference between the 3 versions of various
time zone files? I live in the US-Central time zone and wanted
to set a debian system to London time which means replacing
/etc/localtime to the file that coresponds to London. That's
when I discovered that there are 3 Londons and 3
On Thu, 20 Mar 2014, Martin G. McCormick wrote:
What is the difference between the 3 versions of various time zone
files? I live in the US-Central time zone and wanted to set a debian
system to London time which means replacing /etc/localtime to the file
that coresponds to London. That's when
Hello,
This on a debian wheezy/testing system:
Currently, my time zone is set to 'America/Los_Angeles':
$ cat /etc/timezone
America/Los_Angeles
$ date
Mon Jan 28 11:12:01 PST 2013
Changing it to 'Etc/GMT-8', which should be equivalent to Los Angeles's
time zone results in:
$ echo Etc
Amit wrote:
Currently, my time zone is set to 'America/Los_Angeles':
$ cat /etc/timezone
America/Los_Angeles
$ date
Mon Jan 28 11:12:01 PST 2013
It is easier to work with these by using the TZ variable while
developing and debugging. It avoids the need to change anything
permanently
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
you have done the suggestions above then your clock should be in UTC.
How can I keep the H/W to UTC then
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.00
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.
On Mon, 3 Dec 2012 09:47:44 +
Roger Leigh rle...@codelibre.net wrote:
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.00
1354206971
UTC
[..]
So my system is following the UTC :-)
And
J. B baksh...@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
UTC. What is the advantage of doing that ?
Although time, timezones and clock setting are quite a simple topic it
seems to be major
Ralf Mardorf ralf.mard...@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
Ralf Mardorf ralf.mard...@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
saving time to/from standard time between saving the files using the
BIOS and booting your
Ralf Mardorf ralf.mard...@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
On Sb, 01 dec 12, 14:19:50, Roger Leigh wrote:
[snip]
+100, Informative
Kind regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
signature.asc
Description: Digital signature
On Sat, 1 Dec 2012 14:19:50 +
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
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:
- hardware clock (UTC or local)
- system clock (UTC)
The system clock is *always* UTC. Even if you
On Sat, Dec 01, 2012 at 02:19:50PM +, 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.
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
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
On Wed, 28 Nov 2012 10:37:49 +
Darac Marjal mailingl...@darac.org.uk wrote:
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
On Wednesday 28 November 2012 07:48:28 J. B wrote:
On Wed, 28 Nov 2012 10:37:49 +
Darac Marjal mailingl...@darac.org.uk wrote:
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
On Wednesday 28 November 2012 07:37:49 Darac Marjal wrote:
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
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.
Kind regards,
Andrei
--
Offtopic discussions among Debian users and developers:
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
On Wed, 2012-11-28 at 10:37 +, 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
sometimes store BIOS settings and want the files getting the correct
date.
--
To UNSUBSCRIBE, email 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
the BIOS too.
--
To
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
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
On Wed, 2012-11-28 at 11:48 -0600, green wrote:
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
On Wed, 2012-11-28 at 19:12 +0100, Ralf Mardorf wrote:
On Wed, 2012-11-28 at 11:48 -0600, green wrote:
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
On Wed, 2012-11-28 at 19:17 +0100, Ralf Mardorf wrote:
On Wed, 2012-11-28 at 19:12 +0100, Ralf Mardorf wrote:
On Wed, 2012-11-28 at 11:48 -0600, green wrote:
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
? 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?
By and large, I don't think you will see any issues. Assuming you have
a proper time zone set, your
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
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
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
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
don't store or even recognize the time zone.
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
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
On 28/11/12 03:54 PM, Eike Lantzsch wrote:
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
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
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
this anyway will be handled by special software.
Thank you for the explanation,
Ralf
--
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
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
assumes that the bios clock really is on local
Ralf Mardorf writes:
That's not true, after running ntpdate everything is ok.
Except for anything that happened before ntpdate ran, such as writing
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
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
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
This Intellectual property rubbish is beginning to make me angry.
What now?
Are we expected, each and everyone of us, supposed to pay a stipend to
some johnny-come-lately opportunist?
http://blog.joda.org/2011/10/today-time-zone-database-was-closed.html
Regards,
Weaver.
--
In a world without
-Lately doesn't have a claim
or that the time-zone data wasn't infringing, then no, I see no reason
to pay someone for something they have no right to request payment for.
However, the nice thing about the system is the ability to challenge
such claims. Be thankful you live in a world
package(s) and
seek some other source of the data.
If, however, the court decides that Mr Come-Lately doesn't have a
claim or that the time-zone data wasn't infringing, then no, I see no
reason to pay someone for something they have no right to request
payment for.
However, the nice thing about
[Weaver]
This Intellectual property rubbish is beginning to make me angry.
What now?
Are we expected, each and everyone of us, supposed to pay a stipend to
some johnny-come-lately opportunist?
http://blog.joda.org/2011/10/today-time-zone-database-was-closed.html
This is truly horrible
source of the data.
If, however, the court decides that Mr Come-Lately doesn't have a claim
or that the time-zone data wasn't infringing, then no, I see no reason
to pay someone for something they have no right to request payment for.
However, the nice thing about the system is the ability
Camaleón wrote:
On Tue, 05 Apr 2011 13:16:19 +0300, Dotan Cohen wrote:
Issue One:
I prefer to install Linux distros in English then configure each user
for his own language. While installing Squeeze I do not have the choice
of a time zone for Israel, only US time zones. The installer mentions
of a time zone for Israel, only US time zones. The installer
mentions that to display other time zones I must change language. This
is absurd.
Issue Two:
When I go back and choose the Hebrew language, I _still_ do not get an
option for an Israeli time zone. The time zones available have
switched
Issue One:
I prefer to install Linux distros in English then configure each user
for his own language. While installing Squeeze I do not have the
choice of a time zone for Israel, only US time zones. The installer
mentions that to display other time zones I must change language. This
is absurd
On 04/05/2011 02:16 PM, Dotan Cohen wrote:
Issue One:
I prefer to install Linux distros in English then configure each user
for his own language. While installing Squeeze I do not have the
choice of a time zone for Israel, only US time zones. The installer
mentions that to display other time
1 - 100 of 211 matches
Mail list logo
