Re: BIOS time fine, Linux/Debian's isn't! ...
On Sb, 08 aug 20, 14:38:30, Andrew Cater wrote: > > dpkg-reconfigure -plow tzdata > > [That's the dpkg-reconfigure command, -plow to force asking low priority > questions rather than taking the default answers, and tzdata being the file > that sets the timezone.] As the manpage states, dpkg-reconfigure is using priority low by default. Saves a few keystrokes ;) Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: BIOS time fine, Linux/Debian's isn't! ...
Hi Albretch, If I'm reading your question correctly: Why can't you set the locale for one country, the timezone for a second, the keyboard for a third? You can. As root or equivalent, you can reset timezone with dpkg-reconfigure -plow tzdata [That's the dpkg-reconfigure command, -plow to force asking low priority questions rather than taking the default answers, and tzdata being the file that sets the timezone.] dpkg-reconfigure -plow console-setup [dpkg-reconfigure -plow and then the console-setup program. That might not be installed by default, so you might have to apt-get / apt install console-setup which will reset the keyboard layout that you see in a terminal - UTF-8 is usually a good choice to start with.] dpkg-reconfigure -plow locales will set the system wide language and spelling defaults etc. using the locales package and allow you to switch between locales If you want to be asked all the questions at low priority during the install, consider using the expert install method which will ask _all_ the questions that a standard install sets automatically - if you set your locale to British English during the install, it will provide England/London or GMT as options for timezone and your keyboard to British UK layout, for example. Live well Andy C. On Sat, Aug 8, 2020 at 2:12 PM Albretch Mueller wrote: > On the installer it says: > > Configure clock: if the desired time zone is not listed ... > > Select your time zone: > > > https://manjaro.site/step-by-step-install-debian-9-0-netinstall-version/install-debian-9-0-configure-clock/ > > but why can't you set up your computer as US English and be, say, in > the Ukraine with the time from there? > > lbrtchx > >
Re: BIOS time fine, Linux/Debian's isn't! ...
On the installer it says: Configure clock: if the desired time zone is not listed ... Select your time zone: https://manjaro.site/step-by-step-install-debian-9-0-netinstall-version/install-debian-9-0-configure-clock/ but why can't you set up your computer as US English and be, say, in the Ukraine with the time from there? lbrtchx
Re: Signature [was: BIOS time fine, Linux/Debian's isn't! ...]
writes:
> On Fri, Jul 31, 2020 at 08:55:22AM +0300, Andrei POPESCU wrote:
>> On Jo, 30 iul 20, 17:13:18, Brad Rogers wrote:
>> > On Thu, 30 Jul 2020 17:58:10 +0200
>> > wrote:
>> >
>> > Hello to...@tuxteam.de,
>> >
>> > *PLEASE* fix your sig separator.
>>
>> What difference does it make for a signature like his ("-- t")?
>
> (Thanks, Andrei :-)
>
> And to the OP...
>
> I know, I know. My signature is minimalistic: officially there SHOULD
> be a newline after the space after the dash after the --uh-- dash.
>
> I skip this newline. It's a quirk. I expect a teaspoon or two of
> Postel's Principle [1] applied to me as I grant it to everyone else.
>
> By the way, OP: "WHY DIDN'T YOU CHANGE THE MAIL'S SUBJECT LINE,
> HEIN?"
>
> Phew. Feels better now ;-P
>
> (And please: take this all with a grain of salt).
>
> Cheers
>
> [1] I know... again. There are people who don't really like Postel's
>Principle. I do. I do not want to discuss with you.
>
> -- t
>
My Gnus no problem, cheers up tomas!!!
Sincerely, tomas fan Byung-Hee
--
^고맙습니다 _地平天成_ 감사합니다_^))//
Re: Signature [was: BIOS time fine, Linux/Debian's isn't! ...]
On 2020-07-31 at 10:58, Reco wrote: > On Fri, Jul 31, 2020 at 08:47:50AM -0400, The Wanderer wrote: > >> On 2020-07-31 at 08:37, Reco wrote: >> > It's a kmail thing. mutt, being a superior MUA, is not affected. >> >> Can you clarify both A: in what way this is kmail-specific, > > kmail apparently mistakes '-- t' for the MIME-separator. > > The "offending" e-mail actually look like this: > > == cut == > > -- t > > --gKMricLos+KVdGMg > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: Digital signature > > -BEGIN PGP SIGNATURE- > > == cut == > > Where "-- t" is a signature and is contained inside of a MIME-part, and > "--gKMricLos+KVdGMg" is an actual RFC2045-compilant separator. > > >> and B: what behaviors you're seeing in respect to mutt that are >> relevant here? > > The lack of aforementioned confusion. The signature shows as the > author intended, gpg validation happens as expected. That does indeed look like a kmail bug, as you say. But it's not what I understand the problem being discussed to be. >> I see failure on my end, with Thunderbird, which is similar to what >> I understand the problem being complained about to be. It is my >> understanding that the problem is rooted in (lack of) compliance >> with a particular RFC, such that the resulting behavior will be >> basically universal across all compliant mail clients. > > RFC2045 is a standard, but we all know that certain proprietary MUA > which deliberately violates almost all standards if it comes to > e-mail. Apparently both KDE and Mozilla consider more important to be > compatible with this certain MUA than to follow actual standards > closely. As indicated in another mail, I consider the relevant RFC to be RFC3676, specifically section 4.3. RFC2045 had not entered my scope here, never mind the proprietary MUA you're probably referring to (which, for all I know, may not actually respect RFC3676 either - I should probably test that, actually, next time I have some downtime while on-shift). The original objector has also said that GPG/PGP has nothing to do with his objection, so I suspect that this kmail bug is an unrelated side issue. For what it may be worth, in defense of Mozilla and the people who inherited Thunderbird from them, Tomas' mails validate fine in Thunderbird for me. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Signature [was: BIOS time fine, Linux/Debian's isn't! ...]
On Fri, Jul 31, 2020 at 08:47:50AM -0400, The Wanderer wrote:
> On 2020-07-31 at 08:37, Reco wrote:
> >>> Quirks are fine, when things continue to work. Your sig
> >>> separator fails completely.
> >>
> >> "Fails" in what way? He doesn't actually have a "signature file".
> >> He doesn't have a signature separator ("-- \n") followed by a
> >> signature message. He simply uses "-- t\n\n" at the end of each
> >> email.
> >>
> >> You're not missing out on any content.
> >
> > It's a kmail thing. mutt, being a superior MUA, is not affected.
>
> Can you clarify both A: in what way this is kmail-specific,
kmail apparently mistakes '-- t' for the MIME-separator.
The "offending" e-mail actually look like this:
== cut ==
-- t
--gKMricLos+KVdGMg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-BEGIN PGP SIGNATURE-
== cut ==
Where "-- t" is a signature and is contained inside of a MIME-part, and
"--gKMricLos+KVdGMg" is an actual RFC2045-compilant separator.
> and B: what behaviors you're seeing in respect to mutt that are
> relevant here?
The lack of aforementioned confusion. The signature shows as the author
intended, gpg validation happens as expected.
> I see failure on my end, with Thunderbird, which is similar to what I
> understand the problem being complained about to be. It is my
> understanding that the problem is rooted in (lack of) compliance with a
> particular RFC, such that the resulting behavior will be basically
> universal across all compliant mail clients.
RFC2045 is a standard, but we all know that certain proprietary MUA
which deliberately violates almost all standards if it comes to e-mail.
Apparently both KDE and Mozilla consider more important to be compatible
with this certain MUA than to follow actual standards closely.
Reco
Re: BIOS time fine, Linux/Debian's isn't! ...
On Fri, Jul 31, 2020 at 01:56:10PM +0200, Albretch Mueller wrote: > OK, I will studz and try the manz options you have explain to me. > > > Your posts are sometimes nearly... whimsical. > > Many of you have tell me such things, "you should know that ... " > "why do you even ask if it is so easz to find the answer on the > Internet?" ... Don't take it personally. It was just a short form of "I'm unsure whether I have managed to interpret your meaning correctly, so please watch out for the possibility that I got that totally wrong" or something like that. So please understand that rather as "I'm not sure I've managed to decode you correctly, so watch out and help, please". > Posts are not "whimsical" per se, what makes it so if the impedance > in the assumptions framed by your background and someone else s > conditions/reality. Like right now i have to type using two keyboards > ... Definitely. I was just stating my impression, which has as much to do with me as with you as with the medium in-between. That said, of course "Your posts are ... whimsical" sounds much more absolute than it was meant to. > I am in Germany right now living in a half way house without access > to the Internet ... (you donät want to know more ;-)) Ah, that sound äxciting :) > Also, the kinds of problems I work on (corpora research of free text) > are kind of demanding, zou cant "solve" such problems nicely with OOP > and such paradigms, because zou cant model text with DAGs . That sounds even more exciting. Confusion networks? Cheers -- t signature.asc Description: Digital signature
Re: Signature [was: BIOS time fine, Linux/Debian's isn't! ...]
On 2020-07-31 at 08:37, Reco wrote:
> Hi.
>
> On Fri, Jul 31, 2020 at 07:45:57AM -0400, Greg Wooledge wrote:
>
>> On Fri, Jul 31, 2020 at 10:52:57AM +0100, Brad Rogers wrote:
>>> Quirks are fine, when things continue to work. Your sig
>>> separator fails completely.
>>
>> "Fails" in what way? He doesn't actually have a "signature file".
>> He doesn't have a signature separator ("-- \n") followed by a
>> signature message. He simply uses "-- t\n\n" at the end of each
>> email.
>>
>> You're not missing out on any content.
>
> It's a kmail thing. mutt, being a superior MUA, is not affected.
Can you clarify both A: in what way this is kmail-specific, and B: what
behaviors you're seeing in respect to mutt that are relevant here?
I see failure on my end, with Thunderbird, which is similar to what I
understand the problem being complained about to be. It is my
understanding that the problem is rooted in (lack of) compliance with a
particular RFC, such that the resulting behavior will be basically
universal across all compliant mail clients.
If mutt is somehow managing to produce the behavior which I would would
be called for by the compliant delimiter, despite not seeing such a
delimiter, then I'm curious as to how.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
Re: Signature [was: BIOS time fine, Linux/Debian's isn't! ...]
Hi.
On Fri, Jul 31, 2020 at 07:45:57AM -0400, Greg Wooledge wrote:
> On Fri, Jul 31, 2020 at 10:52:57AM +0100, Brad Rogers wrote:
> > On Fri, 31 Jul 2020 11:28:21 +0200
> > wrote:
> >
> > Hello to...@tuxteam.de,
> >
> > >I skip this newline. It's a quirk. I expect a teaspoon or two of
> >
> > Quirks are fine, when things continue to work. Your sig separator fails
> > completely.
>
> "Fails" in what way? He doesn't actually have a "signature file".
> He doesn't have a signature separator ("-- \n") followed by a signature
> message. He simply uses "-- t\n\n" at the end of each email.
>
> You're not missing out on any content.
It's a kmail thing. mutt, being a superior MUA, is not affected.
Reco
Re: BIOS time fine, Linux/Debian's isn't! ...
OK, I will studz and try the manz options you have explain to me. > Your posts are sometimes nearly... whimsical. Many of you have tell me such things, "you should know that ... " "why do you even ask if it is so easz to find the answer on the Internet?" ... Posts are not "whimsical" per se, what makes it so if the impedance in the assumptions framed by your background and someone else s conditions/reality. Like right now i have to type using two keyboards ... I am in Germany right now living in a half way house without access to the Internet ... (you donät want to know more ;-)) Also, the kinds of problems I work on (corpora research of free text) are kind of demanding, zou cant "solve" such problems nicely with OOP and such paradigms, because zou cant model text with DAGs . lbrtchx
Re: Signature [was: BIOS time fine, Linux/Debian's isn't! ...]
On Fri, Jul 31, 2020 at 10:52:57AM +0100, Brad Rogers wrote:
> On Fri, 31 Jul 2020 11:28:21 +0200
> wrote:
>
> Hello to...@tuxteam.de,
>
> >I skip this newline. It's a quirk. I expect a teaspoon or two of
>
> Quirks are fine, when things continue to work. Your sig separator fails
> completely.
"Fails" in what way? He doesn't actually have a "signature file".
He doesn't have a signature separator ("-- \n") followed by a signature
message. He simply uses "-- t\n\n" at the end of each email.
You're not missing out on any content.
Re: Signature [was: BIOS time fine, Linux/Debian's isn't! ...]
(There is a non-negligible chance that I will be so nervous about the possible contents of replies to this mail that I will not end up ever reading them. I am occasionally subject to bouts of unreasoning terror about such things.) On 2020-07-31 at 05:28, to...@tuxteam.de wrote: > I know, I know. My signature is minimalistic: officially there > SHOULD be a newline after the space after the dash after the --uh-- > dash. > > I skip this newline. It's a quirk. I expect a teaspoon or two of > Postel's Principle [1] applied to me as I grant it to everyone else. > [1] I know... again. There are people who don't really like Postel's > Principle. I do. I do not want to discuss with you. I too like Postel's Principle [1], and I generally apply it to scopes within my control (including this one), or at least try to do so. However, that principle has two halves, and the "send" side is no less important than the "receive" side. I have never heard of, much less am in a position to use, any mail / etc. software which supports detecting and reacting appropriately to the variant of signature delimiter which you are apparently choosing to use. Not all of the software which I use, and potentially not any of it, is something whose behavior is within my scope of control to change in this regard. (Plus, this delimiter is something which is considerably more likely to appear in an actual message body than is the standard [2] delimiter, such that adding support for it would be likely to break things.) By choosing to use such a variant rather than the standard form, you are (apparently deliberately) choosing to not be interoperable with existing software. To me, that does not appear to be consistent with Postel's Principle; you are not being conservative in what you emit. I find it hard to see how "personal idiosyncrasy" (i.e., "quirk") can be enough to excuse this. The effect is very minor in this case, and no worse than the (numerous) people who - whether by choice, by ignorance, or by software limitation - do not use a signature delimiter at all (especially since part of the boilerplate which should be considered the signature - the word "Cheers" - is being placed *before* the delimiter, and so would have to be deleted by hand from a reply anyway). Both the principle and the minor real-world effect, however, remain. I am posting not so much because of your signature delimiter itself or because I can't "be liberal in what I accept" in this regard as because I am genuinely startled by your position on this, and even more by your apparent position in regard to discussing it and the whys of it and so forth. Of all the people whom I have seen more than briefly active on this mailing list in the last several years, you would have been literally the *last* I would have expected to see behave like an asshole other than by accident - even behind myself. (And now I'm nervous about the possibility that this will somehow escalate to the point of mods shutting down the subthread for being offtopic and pushing the Code of Conduct, with the use of that word as part of the reason meaning specific consequences - even if only a reprimand - directed at me. This is probably overreaction, but it's still true.) > (And please: take this all with a grain of salt). I'm honestly not sure what you mean by this, in this context. To take something with a grain of salt is to keep in mind the possibility that it might not actually be true, and in this context, that reads to me as "don't take this seriously, I don't necessarily actually mean it" - but everything else you're saying here seems to indicate that you *do* mean it, so discounting it on that basis would seem inapplicable. I've had to check the calendar at least twice in the course of writing this mail, just to make sure that this wasn't somehow April Fool's Day or some other joke-based reason why you might be doing this without actually being serious about it, since that's the only reason I can think of why you would advise to not believe what you're saying while still bothering to actually stick with the position in this way. If you genuinely are serious about this, then I have lost a level of the respect I had for you. [1] "Be conservative in what you do, be liberal in what you accept from others." https://en.wikipedia.org/wiki/Robustness_principle [2] "Standard" in this context as in, defined by RFC. In this case, that's RFC 3676: https://en.wikipedia.org/wiki/Signature_block#Standard_delimiter https://tools.ietf.org/html/rfc3676#section-4.3 -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Signature [was: BIOS time fine, Linux/Debian's isn't! ...]
On Fri, Jul 31, 2020 at 10:49:14AM +0100, Brad Rogers wrote:
> On Fri, 31 Jul 2020 08:55:22 +0300
> Andrei POPESCU wrote:
>
> Hello Andrei,
>
> >What difference does it make for a signature like his ("-- t")?
>
> It doesn't work.
I won't discuss that further.
Cheers
-- t
signature.asc
Description: Digital signature
Re: Signature [was: BIOS time fine, Linux/Debian's isn't! ...]
On Fri, 31 Jul 2020 11:28:21 +0200 wrote: Hello to...@tuxteam.de, >I skip this newline. It's a quirk. I expect a teaspoon or two of Quirks are fine, when things continue to work. Your sig separator fails completely. -- Regards _ / ) "The blindingly obvious is / _)radnever immediately apparent" It couldn't adapt so it couldn't survive The Great British Mistake - The Adverts pgprJ0shLXTW2.pgp Description: OpenPGP digital signature
Re: BIOS time fine, Linux/Debian's isn't! ...
On Fri, 31 Jul 2020 08:55:22 +0300
Andrei POPESCU wrote:
Hello Andrei,
>What difference does it make for a signature like his ("-- t")?
It doesn't work.
--
Regards _
/ ) "The blindingly obvious is
/ _)radnever immediately apparent"
Give me a reason for living
Call Me Up - Gang of Four
pgpw7gN49xARf.pgp
Description: OpenPGP digital signature
Signature [was: BIOS time fine, Linux/Debian's isn't! ...]
On Fri, Jul 31, 2020 at 08:55:22AM +0300, Andrei POPESCU wrote:
> On Jo, 30 iul 20, 17:13:18, Brad Rogers wrote:
> > On Thu, 30 Jul 2020 17:58:10 +0200
> > wrote:
> >
> > Hello to...@tuxteam.de,
> >
> > *PLEASE* fix your sig separator.
>
> What difference does it make for a signature like his ("-- t")?
(Thanks, Andrei :-)
And to the OP...
I know, I know. My signature is minimalistic: officially there SHOULD
be a newline after the space after the dash after the --uh-- dash.
I skip this newline. It's a quirk. I expect a teaspoon or two of
Postel's Principle [1] applied to me as I grant it to everyone else.
By the way, OP: "WHY DIDN'T YOU CHANGE THE MAIL'S SUBJECT LINE,
HEIN?"
Phew. Feels better now ;-P
(And please: take this all with a grain of salt).
Cheers
[1] I know... again. There are people who don't really like Postel's
Principle. I do. I do not want to discuss with you.
-- t
signature.asc
Description: Digital signature
Re: BIOS time fine, Linux/Debian's isn't! ...
On Jo, 30 iul 20, 17:13:18, Brad Rogers wrote:
> On Thu, 30 Jul 2020 17:58:10 +0200
> wrote:
>
> Hello to...@tuxteam.de,
>
> *PLEASE* fix your sig separator.
What difference does it make for a signature like his ("-- t")?
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
signature.asc
Description: PGP signature
Re: BIOS time fine, Linux/Debian's isn't! ...
On Thu, 30 Jul 2020 17:58:10 +0200 wrote: Hello to...@tuxteam.de, *PLEASE* fix your sig separator. -- Regards _ / ) "The blindingly obvious is / _)radnever immediately apparent" Go away, come back, go away, come back Leave Me Alone (I'm Lonely) - P!nk pgpb8naSj6EgR.pgp Description: OpenPGP digital signature
Re: BIOS time fine, Linux/Debian's isn't! ...
On Thu, Jul 30, 2020 at 03:50:54PM +0100, Brad Rogers wrote: > On Thu, 30 Jul 2020 17:08:19 +0300 > Anssi Saari wrote: > > Hello Anssi, > > >Since Windows 7 it's possible to tell Windows that RTC is UTC. IMO, > >setting RTC to UTC time is the right thing to do, messing around with > > Good to know(1). O/P doesn't state which version of Windows they're > using, so I'll make no further assumptions. > > >Debian settings to accommodate Windows is not. > > I agree, but what with Microsoft and Windows being (almost) ubiquitous, [...] If you have been paying attention, you'd know why /in this case/ an UTC clock makes just a lot of sense. BTW, many moons ago (as of Windows 3.1, go figure), I was part of a programming shop. Our boxes had dual boot, Linux and Windows. To avoid all that stupid problems: among them files "magically" changing their time stamp at each DST transition -- yes, really! imagine the fun with Makefiles -- we set Windows to a time zone on the Greenwich meridian and with no DST. I think it was Liberia or something. We lived with Windows displaying a funny time. But hey. Industry standard. Cheers -- t signature.asc Description: Digital signature
Re: BIOS time fine, Linux/Debian's isn't! ...
On Thu, 30 Jul 2020 17:08:19 +0300 Anssi Saari wrote: Hello Anssi, >Since Windows 7 it's possible to tell Windows that RTC is UTC. IMO, >setting RTC to UTC time is the right thing to do, messing around with Good to know(1). O/P doesn't state which version of Windows they're using, so I'll make no further assumptions. >Debian settings to accommodate Windows is not. I agree, but what with Microsoft and Windows being (almost) ubiquitous, but swathes of companies developing on that platform conforming to standards of their own, things aren't too rosy in that regard. As another example, look at all the bending over backwards developers of various MUAs go through just to accommodate google's (very) broken interpretation of email. Sometimes, whether we like it or not, *we* have to conform to a broken world. :-( (1) I've not used Windows (outside work) in 20 years. At work, I do all I'm required and no more - book holiday, mostly. I have no interest in what goes on under the lid. -- Regards _ / ) "The blindingly obvious is / _)radnever immediately apparent" You only see me for the clothes that I wear Public Image - Public Image Ltd pgpRgkDh6YxoN.pgp Description: OpenPGP digital signature
Re: BIOS time fine, Linux/Debian's isn't! ...
On Thu, Jul 30, 2020 at 05:08:19PM +0300, Anssi Saari wrote: [...] > Since Windows 7 it's possible to tell Windows that RTC is UTC. Wow. They got it right. I'm dumbfounded. >IMO, > setting RTC to UTC time is the right thing to do, messing around with > Debian settings to accommodate Windows is not. Most definitel yes, thanks. Cheers -- t signature.asc Description: Digital signature
Re: BIOS time fine, Linux/Debian's isn't! ...
Brad Rogers writes: > On Thu, 30 Jul 2020 07:19:12 -0400 > Albretch Mueller wrote: > > Hello Albretch, > >> How do you make Linux get the time from the BIOS at start time and >>take it from there? > > Linux *is* reading the RTC; The problem is that Windows expects that > time to be in the local time zone, and sets it so, rather than to UTC, > which Debian (and most Linuxes) expects. You have to tell Debian that is > the case, and all should be well. Since Windows 7 it's possible to tell Windows that RTC is UTC. IMO, setting RTC to UTC time is the right thing to do, messing around with Debian settings to accommodate Windows is not.
Re: BIOS time fine, Linux/Debian's isn't! ...
On Thu, Jul 30, 2020 at 07:19:12AM -0400, Albretch Mueller wrote:
> I used the same laptop with another hard drive with a Windows
> installation which shows the time correctly.
>
> How do you make Linux get the time from the BIOS at start time and
> take it from there?
Your posts are sometimes nearly... whimsical.
By how much is "Debian time" off? In what timezone do you live?
Background (as another poster has already hinted at in this thread):
Windows is totally naive wrt time: it expects the BIOS clock to
reflect the local time (DST included). Therefore, the BIOS clock
has to be massaged twice a year (if your timezone does the DST
thing).
There is a way to tell hwclock to interpret the BIOS clock at boot
time: you set HWCLOCKPARS in /etc/default/hwclock (CAVEAT: UNTESTED!)
like so:
HWCLOCKPARS=-l
("-l" is for "local", the default being "-u" for UTC). In the default
config file, this line is commented out with a '#' at the beginning;
make sure to remove that.
Should HWCLOCKPARS be set to something, just add the "-l" at the end,
separated by some whitespace.
Note that this localtime thing is discouraged, there are some ways
for it to go wrong (notably, local times are ambiguous in the Spring
change).
Microsoft and time. They didn't miss any opportunity to get it wrong.
Each time.
Cheers
-- t
signature.asc
Description: Digital signature
Re: BIOS time fine, Linux/Debian's isn't! ...
On Thu, 30 Jul 2020 07:19:12 -0400 Albretch Mueller wrote: Hello Albretch, > How do you make Linux get the time from the BIOS at start time and >take it from there? Linux *is* reading the RTC; The problem is that Windows expects that time to be in the local time zone, and sets it so, rather than to UTC, which Debian (and most Linuxes) expects. You have to tell Debian that is the case, and all should be well. See; https://www.maketecheasier.com/fix-windows-linux-show-different-times/ -- Regards _ / ) "The blindingly obvious is / _)radnever immediately apparent" The man in a tracksuit attacks me I Predict A Riot - Kaiser Chiefs pgpJk7XToL3SK.pgp Description: OpenPGP digital signature
Re: BIOS time fine, Linux/Debian's isn't! ...
On 7/30/20, Albretch Mueller wrote: > I used the same laptop with another hard drive with a Windows > installation which shows the time correctly. > > How do you make Linux get the time from the BIOS at start time and > take it from there? While you're waiting for others to chime in, this is what I do k/t debootstrap'ing on regular occasion. One of the very first steps in the debootstrap process is to: # editor /etc/adjtime Then fill it with these three lines: 0.0 0 0.0 0 UTC After that, the next (terminal command line) step is: # dpkg-reconfigure tzdata Where we pick from those first choices and then next the more localized spot that echoes our own local times. When the second step completes, the feedback I receive looks like this: Current default time zone: 'America/New_York' Local time is now: Thu Jul 30 07:27:23 EDT 2020. Universal Time is now: Thu Jul 30 11:27:23 UTC 2020. Just learned something new myself here after all this time. If I page down on that second screen (which I NEVER do), it offers "US" as an alternative to "America". When dpkg-reconfigure completes with that option selected, the slightly altered feedback says this instead: Current default time zone: 'US/Eastern' There may be some professional, universal benefit to using one of those versus the other so there they are. Right offhand, I can see where more people around the globe might recognize the geographical location of New York a lot easier than they might be able to distinguish between the United States' usage of Eastern and Central time zones, etc. :) Hope that helps someone out here. Have fun! Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
Re: BIOS time fine, Linux/Debian's isn't! ...
hwclock --hctosys will do it - run a batch file? Or have ntpdate run automatically as the system boots? If you mean that Debian shows a different time to Windows consistently - check that one OS isn't resetting the other's clock. You can persuade Windows _not_ to reset the clock on daylight saving time changes, for example - or you can make sure that they both run in the same timezone and change at the same time.The Debian-specific command: ntpdate-debian will run to the ntp pool set by Debian so that you don't have to specify an NTP server On Thu, Jul 30, 2020 at 11:19 AM Albretch Mueller wrote: > I used the same laptop with another hard drive with a Windows > installation which shows the time correctly. > > How do you make Linux get the time from the BIOS at start time and > take it from there? > > lbrtchx > >
BIOS time fine, Linux/Debian's isn't! ...
I used the same laptop with another hard drive with a Windows installation which shows the time correctly. How do you make Linux get the time from the BIOS at start time and take it from there? lbrtchx
