<div dir="ltr">> 

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?<div>that would actually be very appreciated</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 6, 2019 at 11:46 AM Eike Ziller <<a href="mailto:Eike.Ziller@qt.io">Eike.Ziller@qt.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It sounds to me like any automatically chosen base for 2-digit years will be wrong depending on use case.<br>
For some applications, only the past is relevant.<br>
For some applications, dates N years into the future are relevant.<br>
If we choose any N for a window, that can be wrong for some application.<br>
Even if the format is Qt::SystemLocaleShortDate, we do not know if that refers to the “current date”.<br>
Even if the round trip is made correct for QDate::currentDate(), it will be wrong for other dates.<br>
API that behaves differently depending on current date becomes difficult to test.<br>
<br>
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>
<br>
Br, Eike<br>
<br>
> On Nov 5, 2019, at 14:44, Edward Welbourne <<a href="mailto:edward.welbourne@qt.io" target="_blank">edward.welbourne@qt.io</a>> wrote:<br>
> <br>
> Hi all,<br>
> <br>
> Prompted by [0], I'm looking at what century to use for years, when the<br>
> text being read is expected to be in a "short format" that only includes<br>
> two digits.<br>
> * [0] <a href="https://bugreports.qt.io/browse/QTBUG-74323" rel="noreferrer" target="_blank">https://bugreports.qt.io/browse/QTBUG-74323</a><br>
> <br>
> tl;dr - how do folk feel about (in Qt 6) a century-wide window, ending a<br>
> decade or three ahead of QDate::currentDate(), and placing any two-digit<br>
> year in that range ?<br>
> <br>
> Before anyone says "Don't Do That" (or "why would anyone use two-digit<br>
> years after the mess of y2k ?"), bear in mind that CLDR (the Unicode<br>
> consortium's common locale data repository, on which QLocale's data is<br>
> based) provides short date formats, many of which use two-digit years.<br>
> <br>
> We currently fail to round-trip dates via such formats because 1900 is<br>
> used as default year when no year is specified and (thus) 19 is used as<br>
> default century number when only the later digits are (understood to be)<br>
> specified.  As we get further into the twenty-hundreds (as it were), this<br>
> shall grow to be an increasing jarring flaw in date format handling.<br>
> <br>
> I'm considering changing that: since it's a material behaviour change,<br>
> it clearly needs to happen as part of Qt 6, which at least gives me a<br>
> few months to discuss it and see what folk think is a better plan than<br>
> what we have.<br>
> <br>
> It's notable that ECMAScript's Date constructor adds 1900 to any year<br>
> number from 0 through 99 (even if supplied as one of a sequence of<br>
> integer arguments, not a string), causing problems for the<br>
> representation of dates from 1 BCE through 99 CE.  (I must remember to<br>
> tease my friend on the ECMA 262 committee about that - his excuse will<br>
> be that it was copied from an early version of Java, I suspect - and see<br>
> if he can coax them into changing it.)  Likewise, C's struct tm (used by<br>
> mktime and friends) has a 1900 offset on its year number: that's<br>
> probably never going to change, perverse as it is and shall increasingly<br>
> be.<br>
> <br>
> Folk still talk about "The fifties" and mean the 1950s; probably<br>
> likewise the forties, thirties and even twenties.  That last, at least,<br>
> shall soon be something of a problem.  Folk can see more of the past<br>
> than of the future, so perhaps it's not much of a surprise that common<br>
> nomenclature reserves short phrases for the past at the expense of the<br>
> future: "The sixties" shall be in the past for a few decades yet, I<br>
> think.  So rather than having a default century, and maybe changing it<br>
> abruptly to 20 at some point in the next fifty years, I think it would<br>
> be better to have two-digit years coerced into a century-wide window<br>
> about the (forever moving) present.<br>
> <br>
> Perhaps we should make that a narrower window and treat roughly a decade<br>
> near the wrap-around as error - e.g. using 1945--2035 as our year range,<br>
> with two-digit years 36 through 44 treated as undecodable.<br>
> <br>
> The question then arises: what year-range should we use ?<br>
> <br>
> Two things I'm fairly sure should be true are:<br>
> * the current year (i.e. QDate::currentDate().year(), naturally) should<br>
>  be included in the range;<br>
> * the range should be contiguous.<br>
> <br>
> So the interesting questions are:<br>
> * how far into the past and future should the range reach ?<br>
> * how wide a buffer (if any) should we leave ?<br>
> <br>
> If we don't have a buffer, my inclination is to put the transition date<br>
> at a decade boundary, e.g. 49 -> 2049 but 50 -> 1950, as this shall feel<br>
> less perverse to most folk than having a mid-decade transition such as<br>
> 44 -> 2044 but 45 -> 1945.  However, with a buffer, this problem goes<br>
> away, as there aren't adjacent two-digit numbers that map to wildly<br>
> different years; instead, the intervening numbers that aren't handled<br>
> make the discontinuity seem more sensible.  In principle a one year<br>
> buffer would suffice, but I'm inclined to make the gap a decade long, or<br>
> more, if we have one.<br>
> <br>
> If QDate::currentDate().year() is C and (C / 10) * 10 is D, either of<br>
> these ranges strikes me as better than the 1900--1999 that we're<br>
> currently using:<br>
> * D -70 <= year < D+30 (all two-digit values handled)<br>
> * C -65 <= year <= C +25 (othet two-digit values rejected)<br>
> <br>
> So, to my questions:<br>
> * Does anyone want to make the case for keeping 1900--1999 as range ?<br>
> * Has anyone a better suggestion for how to chose a rolling range ?<br>
> * Should we have a buffer ?  If so, how wide ?<br>
> * How far into the past and future should the range reach ?<br>
> <br>
>       Eddy.<br>
> _______________________________________________<br>
> Development mailing list<br>
> <a href="mailto:Development@qt-project.org" target="_blank">Development@qt-project.org</a><br>
> <a href="https://lists.qt-project.org/listinfo/development" rel="noreferrer" target="_blank">https://lists.qt-project.org/listinfo/development</a><br>
<br>
-- <br>
Eike Ziller<br>
Principal Software Engineer<br>
<br>
The Qt Company GmbH<br>
Erich-Thilo-Straße 10<br>
D-12489 Berlin<br>
<a href="mailto:eike.ziller@qt.io" target="_blank">eike.ziller@qt.io</a><br>
<a href="http://qt.io" rel="noreferrer" target="_blank">http://qt.io</a><br>
Geschäftsführer: Mika Pälsi,<br>
Juha Varelius, Mika Harjuaho<br>
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B<br>
<br>
_______________________________________________<br>
Development mailing list<br>
<a href="mailto:Development@qt-project.org" target="_blank">Development@qt-project.org</a><br>
<a href="https://lists.qt-project.org/listinfo/development" rel="noreferrer" target="_blank">https://lists.qt-project.org/listinfo/development</a><br>
</blockquote></div>