Re: daylight savings nov 2 (US)

Conventions such as DST refer to local time. The shifting of local time for
starting and ending of DST is immediate. Clock adjustments in terms of
speeding up or slowing down the clock refer to the tracking of internal UTC
time within the system. Local time is then calculated as a delta from the
UTC time.

If you "fall back" an hour then local time repeats (though UTC time does
not).

On Thu, Oct 23, 2014 at 5:00 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 23-Oct-2014 14:51 -0500, rob@xxxxxxxxx wrote:

Yes, but neither talks about how the system slows down or speeds up
the clock.

For example, let's say it is the fall switch. It's about 2am on
that Sunday. Time goes to any absolute crawl. From 1:59am to
2:00am takes about an hour. That way you never experience the same
time twice. Of course, writing a million records using timestamp as
the unique key can be 'interesting'. I'm not saying this is exactly
what is happening.

I'm just looking for something that explains how they do this
adjustment.

In essence, very much not literally, because surely the units of time
being dropped or added are much smaller [although I believe them to be
accurate _proportionally_], the following should elucidate:

IIRC, negative _time_adjustment_ is achieved with one _clock_second_
being dropped, for every three _actual_seconds_ of real-time passing. Thus
to adjust one hour back, requires three hours; effectively, two-thirds
capacity.?

IIRC, positive _time_adjustment_ is achieved with one _clock_second_
being added, for every three _actual_seconds_ of real-time passing. Thus to
adjust one hour forward, requires three hours; effectively, capacity
unaffected.?

Given the nature\base of time measurement in seconds and minutes, the
above two paragraphs of text would be accurate for minute(s) in place of
hour(s).

From what I recall was to happen, though I have no actual experience nor
reference docs, was that the DST changes were to be implemented with the
_time_adjustment_ feature rather than the _time_change_ or _time_setting_
feature [of yore], at least on whatever OS and hardware would support the
capability to _adjust_ the time. And without that underlying support, the
time modifications still would be effected as a single _time_change_ of one
hour back or forward in an instant; i.e. the generally undesirable effect
of:
CHGSYSAVL QDATETIME 'new_value' /* or perhaps instead, QHOUR */

--
Regards, Chuck

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.