Re: daylight savings nov 2 (US)

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 */