[Development] Two-digit dates: what century should we use ?

[Eike Ziller]

It sounds to me like any automatically chosen base for 2-digit years will be wrong depending on use case.
For some applications, only the past is relevant.
For some applications, dates N years into the future are relevant.
If we choose any N for a window, that can be wrong for some application.
Even if the format is Qt::SystemLocaleShortDate, we do not know if that refers to the “current date”.
Even if the round trip is made correct for QDate::currentDate(), it will be wrong for other dates.
API that behaves differently depending on current date becomes difficult to test.

If you want to make it easier for people to implement their interpretation of 2-digit years, you could add an (optional) explicit window to the QDate::fromString API?

Br, Eike

> On Nov 5, 2019, at 14:44, Edward Welbourne <edward.welbourne at qt.io> 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 ?
> 
> 	Eddy.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.ziller at qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B