Re: ABSTRACT: Please refer to following table concerning impacts of the leap second change in 2016.

On Tue, Oct 18, 2016 at 4:36 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On 10/18/2016 3:47 PM, Charles Wilt wrote:

I find the idea that your DB has to support 2016-12-31-23.59.60 difficult
to accept...

23.59.60 is a real time.

I think you need to clarify. Is February 29 a real date? Sometimes it
is. But day 29 certainly does not occur every February.

Leap seconds definitely do not happen every day. Since 1972, there
have only been 26 instances when 23.59.60 was a real time.

While a leap day is big enough for ordinary people to notice if it's
missing, leap seconds are utterly inconsequential for the vast, vast,
vast majority of people and businesses.

If DB2 for i can't store all legal values of a timestamp, I think that's
a defect.

If it helps settle your mind, don't think of leap seconds as "valid
values" at all. Just think of 23.59.59 as being twice as long, every
now and then. I'm not kidding. Leap seconds are just noise, well
within the "margin of error". Imagine all the clocks in the world,
including computers. How do they stay synchronized? If they DO stay
synchronized, they do it by pinging a trusted atomic clock server and
making an appropriate adjustment. And they do this frequently! Dozens
if not hundreds (or even thousands) of times more frequently than we
have a leap second. These adjustments are designed to be transparent
to the database. So why can't leap seconds also be?

John Y.