Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #12430 > unrolled thread

what VESA/vga *AM* I useing?

Back to article view | Back to comp.os.linux.misc

Contents

  what VESA/vga *AM* I useing? not.socialnetwork@gmail.com - 2014-10-23 06:07 +0000
    Re: what VESA/vga *AM* I useing? "Nuno J. Silva (aka njsg)" <njsg@invalid.invalid> - 2014-10-23 08:22 +0000
    Re: what VESA/vga *AM* I useing? not.socialnetwork@gmail.com - 2014-10-23 12:04 +0000
      Re: what VESA/vga *AM* I useing? Joe Beanfish <joebeanfish@nospam.duh> - 2014-10-23 13:25 +0000
        Re: what VESA/vga *AM* I useing? not.socialnetwork@gmail.com - 2014-10-24 06:14 +0000
    Re: what VESA/vga *AM* I useing? ebenZEROONE@verizon.net (Hactar) - 2014-10-23 21:45 -0400
      Re: what VESA/vga *AM* I useing? "Nuno J. Silva (aka njsg)" <njsg@invalid.invalid> - 2014-10-24 06:56 +0000
      Re: what VESA/vga *AM* I useing? Unknown <dog@gmail.com> - 2014-10-26 03:07 +0000
    Re: what VESA/vga *AM* I useing? "Chester A. Arthur" <deadprez@whitehouse.com> - 2014-10-23 22:18 -0500
      Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-23 22:09 -0800
        Re: what VESA/vga *AM* I useing? "Nuno J. Silva (aka njsg)" <njsg@invalid.invalid> - 2014-10-24 07:07 +0000
          Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-24 00:02 -0800
        Re: what VESA/vga *AM* I useing? Rich <rich@example.invalid> - 2014-10-24 12:46 +0000
          Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-24 05:39 -0800
            Re: what VESA/vga *AM* I useing? John Hasler <jhasler@newsguy.com> - 2014-10-24 09:31 -0500
              Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-24 08:37 -0800
                Re: what VESA/vga *AM* I useing? John Hasler <jhasler@newsguy.com> - 2014-10-24 12:09 -0500
                  Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-24 09:30 -0800
                    Re: what VESA/vga *AM* I useing? John Hasler <jhasler@newsguy.com> - 2014-10-24 12:44 -0500
                      Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-24 10:15 -0800
                        Re: what VESA/vga *AM* I useing? Rich <rich@example.invalid> - 2014-10-24 18:38 +0000
                          Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-24 11:09 -0800
                            Re: what VESA/vga *AM* I useing? Richard Kettlewell <rjk@greenend.org.uk> - 2014-10-24 21:31 +0100
                              Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-24 12:53 -0800
                                Re: what VESA/vga *AM* I useing? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2014-10-25 13:56 +0100
                                  Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-25 05:12 -0800
                                    Re: what VESA/vga *AM* I useing? John Hasler <jhasler@newsguy.com> - 2014-10-25 09:24 -0500
                                      Re: what VESA/vga *AM* I useing? Rich <rich@example.invalid> - 2014-10-26 00:15 +0000
                        Re: what VESA/vga *AM* I useing? John Hasler <jhasler@newsguy.com> - 2014-10-24 14:17 -0500
                          Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-24 12:55 -0800
                            Re: what VESA/vga *AM* I useing? John Hasler <jhasler@newsguy.com> - 2014-10-24 16:23 -0500
                            Re: what VESA/vga *AM* I useing? Richard Kettlewell <rjk@greenend.org.uk> - 2014-10-24 22:33 +0100
                    Re: what VESA/vga *AM* I useing? Rich <rich@example.invalid> - 2014-10-24 18:28 +0000
                      Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-24 10:43 -0800
                        Re: what VESA/vga *AM* I useing? Rich <rich@example.invalid> - 2014-10-24 22:52 +0000
                      Re: what VESA/vga *AM* I useing? Eef Hartman <E.J.M.Hartman@gmail.com> - 2014-10-24 18:57 +0000
            Re: what VESA/vga *AM* I useing? Rich <rich@example.invalid> - 2014-10-24 17:04 +0000
            Re: what VESA/vga *AM* I useing? Eef Hartman <E.J.M.Hartman@gmail.com> - 2014-10-24 17:09 +0000
              Re: what VESA/vga *AM* I useing? Allodoxaphobia <knock_yourself_out@example.net> - 2014-10-24 21:02 +0000
                Re: what VESA/vga *AM* I useing? John Hasler <jhasler@newsguy.com> - 2014-10-24 16:30 -0500
                  Re: what VESA/vga *AM* I useing? Martin <m@abc.invalid> - 2014-10-25 14:40 +0200
                    Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-25 04:50 -0800
                      Re: what VESA/vga *AM* I useing? John Hasler <jhasler@newsguy.com> - 2014-10-25 09:17 -0500
                        Re: what VESA/vga *AM* I useing? floyd@apaflo.com (Floyd L. Davidson) - 2014-10-25 13:26 -0800
                          Re: what VESA/vga *AM* I useing? John Hasler <jhasler@newsguy.com> - 2014-10-25 16:49 -0500
                      Re: what VESA/vga *AM* I useing? Martin <m@abc.invalid> - 2014-10-25 19:54 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#12453

In comp.os.linux.misc Floyd L. Davidson <floyd@apaflo.com> wrote:
> John Hasler <jhasler@newsguy.com> wrote:
> >Floyd L. Davidson writes:
> >> I've had multiple systems set to local time since the early 90's.
> >> They all switch automatically.
> >
> >I've had multiple systems with the BIOS clock set to UTC since the early
> >90's.  They don't need to switch.  Everything just works.

> If they don't "switch" then you wake up in the morning
> and the all your neighbors have switched, and you aren't
> on the same time they are.

> Run the date command, and you'll see that in fact is
> *has* switched.  In my case one day it says AKDT and the
> next it says AKST.  Or the other way around.

> "Switch" means go from one standard to the other.

If the HW clock and system time are set to UTC, and you unplug your
computer from any network interfaces, and you shutdown all wireless
interfaces (i.e., zero external network connections), and you have your
/etc/localtime file set to your correct local timezone, then the
following will still happen (this is for the USA's switching):


1) if you manually run the "date" command at exactly 01:59:59 on Nov.
2, 2014, it will report 1:59:59 EDT.

2) if you manually run the "date" command exactly one second later
(doing nothing else with date and time), at what would normally be
02:00:00 on Nov. 2, 2014, instead of showing 02:00:00 it will instead
report 01:00:00 EST


Or, if you have a clock running on your desktop, then at 01:59:59 it
will show 01:59:59, and one second later it will show 01:00:00.

I keep a small transparent "oclock" running on screen on most of my
machines.  I've occasionally been using one of the systems at the
instant of the shift.  The hour hand on oclock jumps forward one hour
in the spring, and it jumps back one hour in the fall, at the appointed
times.

But the stored time value (UTC) within both clocks did not change at
all.  The system libraries simply translated to localtime from UTC
automatically for me, and simply performed different translations based
upon what time of the year the request occurred.


That's what is meant by "everything just works".  The clocks do not get
reprogrammed at all, but the visible time to you is the correct time
you expect, even with no sync. to any external network time source.

[toc] | [prev] | [next] | [standalone]

#12456

Rich <rich@example.invalid> wrote:
>That's what is meant by "everything just works".  The clocks do not get
>reprogrammed at all, but the visible time to you is the correct time
>you expect, even with no sync. to any external network time source.

Wrong.  The hardware clock is not changed, but the system clock is.

If the hardware clock is set to local time they both get changed.

-- 
Floyd L. Davidson                         http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)                      floyd@apaflo.com

[toc] | [prev] | [next] | [standalone]

#12458

floyd@apaflo.com (Floyd L. Davidson) writes:
> Rich <rich@example.invalid> wrote:
>> That's what is meant by "everything just works".  The clocks do not
>> get reprogrammed at all, but the visible time to you is the correct
>> time you expect, even with no sync. to any external network time
>> source.
>
> Wrong.  The hardware clock is not changed, but the system clock is.

The system clock is maintained by the kernel, which no idea what
timezone it is or what DST rules are in force; that is domain of the
timezone support code in the C library.  As such if you call time() one
second before a DST change and again one second after the change, the
result will differ by 2.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#12459

Richard Kettlewell <rjk@greenend.org.uk> wrote:
>floyd@apaflo.com (Floyd L. Davidson) writes:
>> Rich <rich@example.invalid> wrote:
>>> That's what is meant by "everything just works".  The clocks do not
>>> get reprogrammed at all, but the visible time to you is the correct
>>> time you expect, even with no sync. to any external network time
>>> source.
>>
>> Wrong.  The hardware clock is not changed, but the system clock is.
>
>The system clock is maintained by the kernel, which no idea what
>timezone it is or what DST rules are in force; that is domain of the
>timezone support code in the C library.  As such if you call time() one
>second before a DST change and again one second after the change, the
>result will differ by 2.

Okay, it isn't the system clock that is changed, it's
the user land interface.  The point is that the output
of the date command will change.

-- 
Floyd L. Davidson                         http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)                      floyd@apaflo.com

[toc] | [prev] | [next] | [standalone]

#12468

On Fri, 24 Oct 2014 12:53:52 -0800
floyd@apaflo.com (Floyd L. Davidson) wrote:
> Richard Kettlewell <rjk@greenend.org.uk> wrote:
> >floyd@apaflo.com (Floyd L. Davidson) writes:
> >> Rich <rich@example.invalid> wrote:
> >>> That's what is meant by "everything just works".  The clocks do
> >>> not get reprogrammed at all, but the visible time to you is the
> >>> correct time you expect, even with no sync. to any external
> >>> network time source.
> >>
> >> Wrong.  The hardware clock is not changed, but the system clock is.
> >
> >The system clock is maintained by the kernel, which no idea what
> >timezone it is or what DST rules are in force; that is domain of the
> >timezone support code in the C library.  As such if you call time()
> >one second before a DST change and again one second after the
> >change, the result will differ by 2.
> 
> Okay, it isn't the system clock that is changed, it's
> the user land interface.  The point is that the output
> of the date command will change.

And to go back to the original point, this means that setting your hw
clock to UTC is much more convenient than setting it to localtime.
As you say, there is no switching, just the output of date changes -
which is how it should be.

Chris

[toc] | [prev] | [next] | [standalone]

#12469

Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
>On Fri, 24 Oct 2014 12:53:52 -0800
>floyd@apaflo.com (Floyd L. Davidson) wrote:
>> Richard Kettlewell <rjk@greenend.org.uk> wrote:
>> >floyd@apaflo.com (Floyd L. Davidson) writes:
>> >> Rich <rich@example.invalid> wrote:
>> >>> That's what is meant by "everything just works".  The clocks do
>> >>> not get reprogrammed at all, but the visible time to you is the
>> >>> correct time you expect, even with no sync. to any external
>> >>> network time source.
>> >>
>> >> Wrong.  The hardware clock is not changed, but the system clock is.
>> >
>> >The system clock is maintained by the kernel, which no idea what
>> >timezone it is or what DST rules are in force; that is domain of the
>> >timezone support code in the C library.  As such if you call time()
>> >one second before a DST change and again one second after the
>> >change, the result will differ by 2.
>>
>> Okay, it isn't the system clock that is changed, it's
>> the user land interface.  The point is that the output
>> of the date command will change.
>
>And to go back to the original point, this means that setting your hw
>clock to UTC is much more convenient than setting it to localtime.
>As you say, there is no switching, just the output of date changes -
>which is how it should be.

Why is that "how it should be"?  It doesn't make life better...

-- 
Floyd L. Davidson                         http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)                      floyd@apaflo.com

[toc] | [prev] | [next] | [standalone]

#12471

Floyd L. Davidson writes:
> Why is that "how it should be"?  It doesn't make life better...

No need for the admin to create any scripts and/or cron jobs, each user
can easily have her own timezone (useful for remote logins), timestamps
are always correct,  if you travel with the machine you can set your
timezone appropriately with trivial ease...

It just works as installed.  No configuration other than answering the
question about the default timezone.
-- 
John Hasler 
jhasler@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#12478

In comp.os.linux.misc John Hasler <jhasler@newsguy.com> wrote:
> Floyd L. Davidson writes:
> > Why is that "how it should be"?  It doesn't make life better...

> No need for the admin to create any scripts and/or cron jobs, each user
> can easily have her own timezone (useful for remote logins), timestamps
> are always correct,  if you travel with the machine you can set your
> timezone appropriately with trivial ease...

> It just works as installed.  No configuration other than answering the
> question about the default timezone.

I am beginning to suspect the issue here stems from a difference in
viewpoint on the OP's part about how time is stored/displayed.

I am suspecting that when the OP says "system time" he is
referring/viewing only the outermost shell of the onion (the "date"
command output), and that when he says "system time" he means that he
types "date" into a shell and see's local time printed out by the
"date" command,

Most of the rest of us are discussing this with him using a definition
of "system time" that unwraps several layers of the onion, such that
"system time" and "output of 'date' command" are two very different
items in our minds.  

I.e., we are talking about this four layer onion:

hardware clock (inner most layer - set to UTC)
    |
    |<--read at boot
    |
linux "system time" (also set to UTC) (layer 2)
    |
    |<--read (at least) by glibc time functions
    |
glibc time zone handling library code (layer 3)
(performs translation of UTC into localtime)
    |
    |<--request from 'date' to glibc for "current time" 
    |
  date command (outer shell of onion, layer 4) 

And when we talk about "system clock" it is not the output of the
'date' command, but the time value the kernel stores internally, that
is read by the glibc time library functions, and translated into
localtime therein, then handed off to the 'date' command to simply be
formatted for human viewing.


The reason I am beginning to think the OP is viewing just the outer
shell is his continued insistence that his clock is set in local time,
but that he is also using ntpdate to set his system clock.  As has been
stated a few times by others, NTP itself knows only UTC.  So unbeknowst
to the OP, his system clock (and maybe his hardware clock as well) is
actually set to UTC, But because he see's localtime from the 'date'
command, in his mind his system clock is set to localtime.

[toc] | [prev] | [next] | [standalone]

#12457

Floyd L. Davidson writes:
> If they don't "switch" then you wake up in the morning and the all
> your neighbors have switched, and you aren't on the same time they
> are.

Nothing switches.  The system clock stays in UTC.  The BIOS clock stays
in UTC.  Consequently when I boot up from power off the system clock is
always set correctly.

> Run the date command, and you'll see that in fact is *has* switched.
> In my case one day it says AKDT and the next it says AKST.  Or the
> other way around.

Nothing has switched.  When I run date the relevant library call looks
at my environment and converts from UTC after consulting the appropriate
table:

thumper/~ 19 date
Fri Oct 24 14:02:19 CDT 2014
thumper/~ 19 TZ=America/Anchorage date
Fri Oct 24 11:07:10 AKDT 2014



-- 
John Hasler 
jhasler@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#12460

John Hasler <jhasler@newsguy.com> wrote:
>Floyd L. Davidson writes:
>> If they don't "switch" then you wake up in the morning and the all
>> your neighbors have switched, and you aren't on the same time they
>> are.
>
>Nothing switches.  The system clock stays in UTC.  The BIOS clock stays
>in UTC.  Consequently when I boot up from power off the system clock is
>always set correctly.

The output of the date command is changed.  Call it whatever you wish,
but something is switched.

>> Run the date command, and you'll see that in fact is *has* switched.
>> In my case one day it says AKDT and the next it says AKST.  Or the
>> other way around.
>
>Nothing has switched.  When I run date the relevant library call looks
>at my environment and converts from UTC after consulting the appropriate
>table:
>
>thumper/~ 19 date
>Fri Oct 24 14:02:19 CDT 2014
>thumper/~ 19 TZ=America/Anchorage date
>Fri Oct 24 11:07:10 AKDT 2014

So something does get switched!

-- 
Floyd L. Davidson                         http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)                      floyd@apaflo.com

[toc] | [prev] | [next] | [standalone]

#12462

Floyd L. Davidson writes:
> So something does get switched!

No event occurs when the moment of your local DST<->ST change passes:
Linux takes no notice of that.  No "I'm on Daylight Savings Time" or
"I'm on Standard Time" state is maintained.  The database is simply
consulted to convert UTC to whatever local time you have indicate that
you want to see when you run date (or anything else that makes the
relevant library calls).
-- 
John Hasler 
jhasler@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#12463

floyd@apaflo.com (Floyd L. Davidson) writes:
> John Hasler <jhasler@newsguy.com> wrote:
>>Nothing has switched.  When I run date the relevant library call looks
>>at my environment and converts from UTC after consulting the appropriate
>>table:
>>
>>thumper/~ 19 date
>>Fri Oct 24 14:02:19 CDT 2014
>>thumper/~ 19 TZ=America/Anchorage date
>>Fri Oct 24 11:07:10 AKDT 2014
>
> So something does get switched!

Only if ‘switched’ can involve nothing whatsoever happening.  There is
no persistent flag recording whether DST is in force right now, so no
specific action is taken at the moment of a DST transition.  The C
library works it out each time a conversion is requested.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#12452

In comp.os.linux.misc Floyd L. Davidson <floyd@apaflo.com> wrote:
> John Hasler <jhasler@newsguy.com> wrote:
> >Floyd L. Davidson writes:
> >> The only way I know when the switch takes place is when I notice my
> >> computer is an hour different than my wall clock.
> >
> >I wrote:
> >> Same here with the BIOS clock set to UTC.  So what is the advantage of
> >> setting it to local time and having to change it manually twice a year?
> >
> >Floyd L. Davidson writes:
> >> So why would anyone manually change it?
> >
> >If you don't it will only be on local time part of the year.

> I've had multiple systems set to local time since the
> early 90's.  They all switch automatically.

> A cron job sets the time with ntpdate.

Ah, this might be why then.  Ntpdate might also be applying DST
translations for you, and you see the clock shift.

My statements were based upon setting HW clock and system time in UTC,
and then the shift occurs automatically, even with no network
connection to anything running.

> Another cron job sets the hardware clock from the system clock.  Both
> run once an hour.

> It's all automatic.

Yes, and ntpdate is likely why you are seeing auto DST shift changes. 
Without it, you would not see the time shift on the computer either.

> The big problem is my wall clock... I have to manually set it.

They do make wall clocks now that sync to transmitted time signals and
auto-set themselves.  Although depending upon where you are located
geographically will determine if such would even work for you.

[toc] | [prev] | [next] | [standalone]

#12454

Rich <rich@example.invalid> wrote:
>In comp.os.linux.misc Floyd L. Davidson <floyd@apaflo.com> wrote:
>> John Hasler <jhasler@newsguy.com> wrote:
>> >Floyd L. Davidson writes:
>> >> The only way I know when the switch takes place is when I notice my
>> >> computer is an hour different than my wall clock.
>> >
>> >I wrote:
>> >> Same here with the BIOS clock set to UTC.  So what is the advantage of
>> >> setting it to local time and having to change it manually twice a year?
>> >
>> >Floyd L. Davidson writes:
>> >> So why would anyone manually change it?
>> >
>> >If you don't it will only be on local time part of the year.
>
>> I've had multiple systems set to local time since the
>> early 90's.  They all switch automatically.
>
>> A cron job sets the time with ntpdate.
>
>Ah, this might be why then.  Ntpdate might also be applying DST
>translations for you, and you see the clock shift.
>
>My statements were based upon setting HW clock and system time in UTC,
>and then the shift occurs automatically, even with no network
>connection to anything running.

Your statement was "and having to change it manually".

That just isn' the case.

>> Another cron job sets the hardware clock from the system clock.  Both
>> run once an hour.
>
>> It's all automatic.
>
>Yes, and ntpdate is likely why you are seeing auto DST shift changes.
>Without it, you would not see the time shift on the computer either.

But I do see it all work automatically.  That's what a
good systems admin sets the system up to do... ;-)

>> The big problem is my wall clock... I have to manually set it.
>
>They do make wall clocks now that sync to transmitted time signals and
>auto-set themselves.  Although depending upon where you are located
>geographically will determine if such would even work for you.

The don't work at 71 degrees north latitude.

Oh, I forgot, there is another problem...  my danged
cameras don't auto switch either.  Nor do my printers.

For the life of me I cannot understand why Nikon and
Epson both have not put an embedded Linux system into
every product they make!  Damned foolish, considering
the vast benefits.  Epson in particular has a crude
human interface that reminds of what was being done in
the 80's with 8085 and Z80 microprocessors.  It's
ridiculous, and so easy to fix.

-- 
Floyd L. Davidson                         http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)                      floyd@apaflo.com

[toc] | [prev] | [next] | [standalone]

#12465

In comp.os.linux.misc Floyd L. Davidson <floyd@apaflo.com> wrote:
> Your statement was "and having to change it manually".

> That just isn' the case.

If you set the clock to local time, and you have no network
connection, then you _will_ have to manually change the clock in the
computer manually after the switchover occurs.

The auto-adjust only works if you have the clock set to UTC, have your
timezone configured correctly, and let the C libs do the necessary math
conversion when you request time.

The reason you see auto-adjust with the clock set to local time is very
likely the result of your ntpdate cron job.  So yes, you get automatic
changing, but because of external network accesses.

If you used utc, and a properly configured timezone, you'd still see
local time for all your clock/date outputs, but you would get the
auto-switch over even without any external network connection.

> >Yes, and ntpdate is likely why you are seeing auto DST shift
> >changes. Without it, you would not see the time shift on the
> >computer either.

> But I do see it all work automatically.  That's what a good systems
> admin sets the system up to do... ;-)

Yes, you do, but only because of this extra setup on your part.

If you used UTC as the system time, and told the C libraries your
proper timezone, you would not need the extra setup to get DST changes
to happen.

You'd only need the extra setup to keep your clock from drifting too
far away from reality.

[toc] | [prev] | [next] | [standalone]

#12455

In alt.os.linux.slackware Rich <rich@example.invalid> wrote:
> Ah, this might be why then.  Ntpdate might also be applying DST
> translations for you, and you see the clock shift.

Actually no.

What no-one yet mentioned (and I almost forgot myself) the Unix/Linix
time is _always_ in UTC (seconds since the epoch = 1 Jan 1970 0:00:00
UTC), so the localtime vs UTC issue is only when using the hw clock
(which doesn't have a timezone field), if you're always ON or even
online with ntpd running it is a non-issue.
From the "man 7 time" page:
       Unix systems represent time in seconds since the Epoch, which is
       defined as 0:00:00 UTC on the morning of 1 January 1970

So only when setting the system time from the hw clock (at boot-up) or
storing it again TO the hw clock (at shutdown) an optional conversion
from/to localtime is made (but isn't needed when the hw clock is in UTC
too).
That is also why the issue goes away if your system is on at the actual
change, because the conversion at the next reboot/shutdown is done in
the "current" timezone, that is with or without (depending on which
change this was) DST correction.

PS: Slackware's default NTP config allows a "big jump" at bootup, so if
you boot-up after a DST change from a "localtime" hw clock the ntp
daemon will adjust it with the needed hour.
Normally ntpd allows for a maximum adjustment of (by default) 1000 s, so
wouldn't accept a 1 hour change.

[toc] | [prev] | [next] | [standalone]

#12446

In comp.os.linux.misc Floyd L. Davidson <floyd@apaflo.com> wrote:
> Rich <rich@example.invalid> wrote:
> >In comp.os.linux.misc Floyd L. Davidson <floyd@apaflo.com> wrote:
> >> >Localtime is crazy, the rules change and there are so many
> >> >strangenesses. (The world ends at midnite-12:30 Newfie time).
> >> >There is software to deal with that, and it works well if it
> >> >isn't bypassed by OSes that make poor choices.
> >
> >> You're making life much more difficult than it need be.
> >
> >And setting the hardware clock to UTC lets the system libs take care
> >of that crazyness, so that one's computer time automatically moves
> >forward at 2am in the spring, and automatically falls back at 2am in
> >the fall, with no effort on the users part.

> Setting to local time does not change that.

Interesting.  That's not been my experience (but the last time I had
anything set to local in the HW clock was likely sometime around 1995,
so things just might have improved since then).

But at least at one point in the past, if you wanted automatic
adjustment of D/S time switches, the hardware clock needed to be set to
UTC, system time needed to be UTC, and one's /etc/localtime file had to
be copied from (or symlinked to) the proper zoneinfo file for the
location of the machine.

Once the /etc/localtime was set properly, then all times displayed as
local, even though underneath the clocks were set to UTC.

[toc] | [prev] | [next] | [standalone]

#12447

In alt.os.linux.slackware Floyd L. Davidson <floyd@apaflo.com> wrote:
>>forward at 2am in the spring, and automatically falls back at 2am in
>>the fall, with no effort on the users part.
> 
> Setting to local time does not change that.

ONLY when the computer is UP at the time of change, as now the change is
done by resetting the hw clock AT that time (localtime changes!).
When you shutdown the previous evening and boot-up the next day,
the system doesn't know the hw clock is now off by one hour so the
whole system time will be off too.

[toc] | [prev] | [next] | [standalone]

#12461

On 24 Oct 2014 17:09:05 GMT, Eef Hartman wrote:
> In alt.os.linux.slackware Floyd L. Davidson <floyd@apaflo.com> wrote:
>>>forward at 2am in the spring, and automatically falls back at 2am in
>>>the fall, with no effort on the users part.
>> 
>> Setting to local time does not change that.
>
> ONLY when the computer is UP at the time of change, as now the change is
> done by resetting the hw clock AT that time (localtime changes!).
> When you shutdown the previous evening and boot-up the next day,
> the system doesn't know the hw clock is now off by one hour so the
> whole system time will be off too.

 *NOT* my experience here.  And this system is *ALWAYS* off overnight 
 when The Change occurs -- going back 15 years.

Jonesy
-- 
  Marvin L Jones    | Marvin      | W3DHJ  | linux
   38.238N 104.547W |  @ jonz.net | Jonesy |  OS/2
    * Killfiling google & XXXXbanter.com: jonz.net/ng.htm

[toc] | [prev] | [next] | [standalone]

#12464

Allodoxaphobia writes:
> *NOT* my experience here.  And this system is *ALWAYS* off overnight 
>  when The Change occurs -- going back 15 years.

How is your BIOS clock getting set forward or back an hour in order to
continue to reflect local time after the Change occurs?
-- 
John Hasler 
jhasler@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web