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

On 10/19/2016 5:12 PM, John Yeung wrote:

On Wed, Oct 19, 2016 at 11:59 AM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

The database people seem to have the weird rules for the date part of a
time stamp implemented. This argues that they ought to be able to
implement the weird rules for the time portion as well.

Ah, but the date part follows rules. Moreover, these rules are 100%
deterministic.

Leap seconds are unpredictable. There is no one in the universe who
can tell you with certainty TODAY whether 2018-12-31-23.59.60 will be
a valid timestamp or not.

We all of us know with complete certainty TODAY that 2016 will get a
leap second. Leap seconds are announced well in advance, much the same
way (legislated) changes to summer time are announced well in advance.
No, we don't know about 2018 yet, but we got almost 6 months advance
notice about 2016.

http://www.usno.navy.mil/USNO/tours-events/2016_Leap_Second%20Press%20Release%20-%20Final.pdf

ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat

When some legislature alters the date that summer time will end and
begin, IBM, like everyone else, issue patches. When a leap second is
announced, IBM can release a PTF. That PTF doesn't have to allow /all/
minutes to have second number 60; only minute 23.59 on 31 Dec. This is
exactly like allowing Feb 29 only on particular years.

I (barely) understand why IBM would argue against this - it means ugly
work and even uglier testing. I don't understand why any of us would
argue against the ability of DB2 to store and manipulate /every single/
legal time stamp.

Tellingly, Oracle, Microsoft SQL Server, PostgreSQL, and MySQL
all disallow values above 59 for the second. So, would you
rather have DB2's timestamp be more like C's and POSIX's,
or more like all the other big-name databases in the world?

I'd rather DB2 didn't suck as much as Oracle, SQL Server, Postgres, and
MySQL do.