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

On 10/20/2016 6:59 PM, John Yeung wrote:

Buck, I'm not arguing against being able store all valid timestamps.
If IBM can and wants to implement it, I'm 100% fine with that.

I will forward the results of my PMR. Based on my inability to clearly
state the issue here, I'm not hopeful that I can do so with IBM either.

What I'm arguing is (1) that it's not particularly bad if there isn't
any provision for storing leap seconds as distinct timestamps,

Why not? Let's argue from a silly position to make the point. If you
have a DB2 INT and the database refused to store 65530, would that be OK
because the database doesn't need to store /all/ legal values of INT,
only /most/ of them?

It was (and remains) a wrenching change to move from 'char is 8 bits' to
'char is whatever it takes to represent a character'; to move from ASCII
to Unicode. Better, more accurate abstractions are the hallmark of good
computing. When we as a community find a deficiency, it behooves us to
at least attempt to get that deficiency addressed.

and (2)
allowing for storage of distinct leap-second timestamps will either
mean you have to also open the door for a whole lot of invalid
timestamps (vastly more numerous than the valid ones you're adding),

What makes that /necessary/?

or you have to have a costly, complex, and brittle system to prevent
invalid values and adjust calculations for the new valid ones.

Date and time handling is weird stuff. Weird enough that generations of
programmers have been told in no uncertain terms to Use Well Known
Libraries rather than rolling their own. And yet, the authors of those
libraries have managed to deal with mod(60), mod(24), mod(30 days hath
September etc). It's not at all clear to me how continued reliance on
an /improved/ set of library routines makes my system more fragile.

In fact, the fragility will almost certainly go up when I do my Y2k16
remediation to hunt down all the places in my code base where a
TIMESTAMP gets modified, and add a procedure call to alter 23.59.60 to
23.59.59 before feeding that to the TIMESTAMP. Bearing in mind that I
can't actually /use/ a TIMESTAMP as input to this procedure, so there
will be conversions to and from character.

For example, are you proposing that we should be able to enter
1901-06-30-23.59.60 today, as a valid value?

No. There was no leap second in 1901.

How about 2018-12-31-23.59.60?

No. If there is no leap second announcement, there is no leap second
PTF. Without that PTF, this future stamp is not a leap second, by
definition.

If we enter the latter, and consider it valid
today, what happens in a couple of years if it turns out we never did
take that leap second? Does it then become invalid?

Why would IBM issue a leap second PTF without an announcement that a
leap second is planned?

The situation is not like what we have for leap days, which can be
determined through pure calculation. We don't have to wait for someone
to announce that a leap day will be inserted or not.

We don't need to store /future/ instances of leap seconds in our
database /today/. What we do need is the ability to store /past/ leap
seconds in our database /today/. And for the purposes of this
discussion, /past/ means 'zero or more seconds ago'.