> 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? that would actually be very appreciated
On Wed, Nov 6, 2019 at 11:46 AM Eike Ziller <eike.zil...@qt.io> wrote: > 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.welbou...@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@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.zil...@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 > > _______________________________________________ > 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
