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 UTC,
ces which 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 i
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 DVD[
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
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 n
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 ca
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 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/r
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" tim
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
>
> ###
> #
> htt
> 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
ty
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
###
#
https://stackoverflow.com/questions/1092631/get-current-t
-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'
-BEGIN PGP MESSAGE-
Charset: utf-8
Version: GnuPG v2.0.19 (GNU/Linux)
hQEMA07UmgrFcS2hAQf/dwmi7WfCdgUxzk0BIhdGs9qKWgbRiiVyqxLm2Min3wqF
Xw6mgqsMBh3vQ24CCVmPTF4q2eiy2ZMsGjsFwXm2SJK8WrgsSOKSFtyt77rZHpHx
SExwcy/nXHoSaynm9x3dNwfy2qcrANSmG9dWBiX3HUc1GSw08DVa50D+iqZBmyWH
csubGvcXMxbvYBAKwFZniS2Nr
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 sy
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 cop
Ron Leach 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 GMT is the same as
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 se
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
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
Un
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 sta
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 outwei
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 read
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: https://lists.de
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 debian-
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 an
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 w
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
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
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 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 acco
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 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. The
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
>
Ahoj,
Dňa Fri, 21 Mar 2014 16:18:22 + Brian
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 (eg. Windows) a
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 /e
. 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
Ahoj,
Dňa Fri, 21 Mar 2014 10:57:08 + Ron Leach
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. If
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
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/loc
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 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 Lo
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
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 avo
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
Ralf Mardorf 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.o
Ralf Mardorf 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 Linux system the kernel w
Ralf Mardorf 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.
"J. B" 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
On Mon, 3 Dec 2012 09:47:44 +
Roger Leigh 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 a
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 g
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
On Sat, 1 Dec 2012 14:19:50 +
Roger Leigh wrote:
> 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
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, 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
> >
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. Ev
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
Ar
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 cl
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
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 No
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 UNSUBSC
; 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 iss
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 sy
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. W
ote that BIOS clocks 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
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 in
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
hink you will see any issues.
Exactly, there are no issues when using Linux with the hardware clock
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.
>
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 spi
ntage, 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 computer will repeat an hour every year.
That might cause problems (if your computer is on during that hour).
But thes
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
> > >
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 nei
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 Linu
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
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.
> >
> > Th
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 UNSUBSC
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 debian-u
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 th
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:
http://lists.alioth.debian.org/mailman
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
On Wednesday 28 November 2012 07:48:28 J. B wrote:
> On Wed, 28 Nov 2012 10: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 beg
On Wed, 28 Nov 2012 10: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 a
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
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 t
y have to drop the relevant 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 r
[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.h
y have to drop the relevant 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
ides 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 to challenge
such claims. Be thankful you liv
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
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.
>>>
>>> Issue Two:
>>> When I go back
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
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 mentio
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 zones I must change
1 - 100 of 205 matches
Mail list logo
