Hi,
On 05-11-19 14:44, Edward Welbourne wrote:
Hi all,
Prompted by [0], I'm looking at what century to use for years, when the
text being read is expected to be in a "short format" that only includes
two digits.
* [0] https://bugreports.qt.io/browse/QTBUG-74323
tl;dr - how do folk feel about (in Qt 6) a century-wide window, ending a
decade or three ahead of QDate::currentDate(), and placing any two-digit
year in that range ?
Before anyone says "Don't Do That" (or "why would anyone use two-digit
years after the mess of y2k ?"), bear in mind that CLDR (the Unicode
consortium's common locale data repository, on which QLocale's data is
based) provides short date formats, many of which use two-digit years.
We currently fail to round-trip dates via such formats because 1900 is
used as default year when no year is specified and (thus) 19 is used as
default century number when only the later digits are (understood to be)
specified. As we get further into the twenty-hundreds (as it were), this
shall grow to be an increasing jarring flaw in date format handling.
I'm considering changing that: since it's a material behaviour change,
it clearly needs to happen as part of Qt 6, which at least gives me a
few months to discuss it and see what folk think is a better plan than
what we have.
It's notable that ECMAScript's Date constructor adds 1900 to any year
number from 0 through 99 (even if supplied as one of a sequence of
integer arguments, not a string), causing problems for the
representation of dates from 1 BCE through 99 CE. (I must remember to
tease my friend on the ECMA 262 committee about that - his excuse will
be that it was copied from an early version of Java, I suspect - and see
if he can coax them into changing it.) Likewise, C's struct tm (used by
mktime and friends) has a 1900 offset on its year number: that's
probably never going to change, perverse as it is and shall increasingly
be.
Folk still talk about "The fifties" and mean the 1950s; probably
likewise the forties, thirties and even twenties. That last, at least,
shall soon be something of a problem. Folk can see more of the past
than of the future, so perhaps it's not much of a surprise that common
nomenclature reserves short phrases for the past at the expense of the
future: "The sixties" shall be in the past for a few decades yet, I
think. So rather than having a default century, and maybe changing it
abruptly to 20 at some point in the next fifty years, I think it would
be better to have two-digit years coerced into a century-wide window
about the (forever moving) present.
Perhaps we should make that a narrower window and treat roughly a decade
near the wrap-around as error - e.g. using 1945--2035 as our year range,
with two-digit years 36 through 44 treated as undecodable.
The question then arises: what year-range should we use ?
Two things I'm fairly sure should be true are:
* the current year (i.e. QDate::currentDate().year(), naturally) should
be included in the range;
* the range should be contiguous.
So the interesting questions are:
* how far into the past and future should the range reach ?
* how wide a buffer (if any) should we leave ?
If we don't have a buffer, my inclination is to put the transition date
at a decade boundary, e.g. 49 -> 2049 but 50 -> 1950, as this shall feel
less perverse to most folk than having a mid-decade transition such as
44 -> 2044 but 45 -> 1945. However, with a buffer, this problem goes
away, as there aren't adjacent two-digit numbers that map to wildly
different years; instead, the intervening numbers that aren't handled
make the discontinuity seem more sensible. In principle a one year
buffer would suffice, but I'm inclined to make the gap a decade long, or
more, if we have one.
If QDate::currentDate().year() is C and (C / 10) * 10 is D, either of
these ranges strikes me as better than the 1900--1999 that we're
currently using:
* D -70 <= year < D+30 (all two-digit values handled)
* C -65 <= year <= C +25 (othet two-digit values rejected)
So, to my questions:
* Does anyone want to make the case for keeping 1900--1999 as range ?
* Has anyone a better suggestion for how to chose a rolling range ?
* Should we have a buffer ? If so, how wide ?
* How far into the past and future should the range reach ?
I came to the conclusion that the sane behavior for interpreting dates
depends on the semantics of what the date means. For instance, a birth
date will always be a date in the past, while a date for an appointment
would normally be a date in the future. That alters the interpretation
of the date. May I suggest adding an enum argument to any function doing
the conversion from a string to a date that allows you tell you to
suggest the kind of date that is expected?
I think it would come in four flavors. 1) A default `aroundCurrentDate`
value or something like that that would result in using a window where
the date is interpreted as being in the window of the current year - 50
and the current year + 50 years. 2) A `pastDate` value that would result
in interpreting the date as meaning anywhere in the past 100 years. 3) A
`futureDate` value that would result in interpreting the date as
anywhere in the future 100 years, and 4) a `legacy1900` value that would
revert back to the current behavior and just adds 1900.
Cheers,
André
Eddy.
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
