On Fri, Oct 21, 2016 at 1:37 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:
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.
I'm sorry to say that I seem to have equal inability to clearly state
my viewpoint.
On 10/20/2016 6:59 PM, John Yeung wrote:
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?
Buck, that is indeed a silly position. It's too silly to make your
point. A large part of my argument for why the status quo isn't
horrible is that changing the TIMESTAMP data type to allow leap
seconds would complicate the math. Integers are among the nicest,
cleanest, simplest types for math, and putting in arbitrary holes
would not be an improvement. What's (65529 + 1)? Is it NULL? Is it
65531? What?
Worse, what if 65530 is not OK now, but it turns out that it is OK
next year? And what if I'm trying to exchange data with someone who is
behind (or ahead) on their integer PTFs relative to me?
From this point of view, leap seconds are the opposite of clean and simple.
Now, it's true that dates are already pretty weird, and months in
particular are just crazy, but the rules governing them haven't
changed in hundreds of years and won't change for (at least) hundreds
of years more. So while they're not clean the way integers are,
they're stable and 100% predictable for several human lifetimes. I can
write date calculation routines today, purely in code (no periodically
updated look-up tables), and they will be correct until the computer
that is running them is so old that it is malfunctioning from wear or
decay.
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.
Very true. But Unicode has something that leap seconds do not: It is
of very high importance to a very large number of people. It has
revolutionized international computing. Its benefits are visible to
ordinary people around the world. The *business case* for Unicode is a
no-brainer.
How many people's lives would be materially improved by accommodating
leap seconds? How many businesses?
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.
Let's be careful how we define "better". As I'm sure you can
appreciate, what is better for one person or from one point of view
might be worse for someone else or looking at it a different way.
I think the daylight saving issue is a good example of this. Clearly,
enough people thought it would be "better" to adjust the clocks that
they made it happen. I'm sure plenty of people still feel this way.
But an increasing number of people are finding that for them, in
today's world, adjusting the clocks is really not better than leaving
the clocks alone, and in fact is noticeably worse.
So I ask again, how many people's lives would be materially improved
by accommodating leap seconds? How many businesses?
[Revisiting date calculations]
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.
I'm not sure I understand: what is "improved" over what, exactly? If
you mean industrial-strength libraries written by experts in date math
are an improvement over the average programmer's home-grown date
routines, sure, I can go with that.
If you mean the Gregorian calendar was an improvement over the Julian
calendar, which in turn was an improvement over the notion that each
year should consist of *exactly* 12 months, of *exactly* 30 days each,
then once again, I can go with that.
But be careful to note the magnitude of the accuracy improvements, and
the effect it had on people's lives. While the 360-day year had the
desirable property of being clean and consistent, it was unusably
inaccurate. Ordinary people would notice the seasons rapidly drifting.
It was worth the complexity to make the year longer.
(Having July and August both 31 days, and February a runt, is
certainly not "worthwhile complexity", but we also have to weigh the
cost of upending the established system.)
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.
I'm fine with "no" as an answer. I'm a little concerned about your
rationale. If you are arguing for historical accuracy, then are you
saying DB2 should allow 1900-02-29 in its date fields, to accommodate
the fact that Russia had not yet adopted the Gregorian calendar by
that date, and thus observed the perfectly valid Julian leap day? For
that matter, shouldn't DB2 allow Feb 29 as a valid date *every* year,
since many religious institutions *still* use the unrevised Julian
calendar? How about 1712-02-30, which was a real date in Sweden?
John Y.
midrange.com
