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

[Eike Ziller]

> On 6. Nov 2019, at 13:38, Edward Welbourne <edward.welbourne at qt.io> wrote:
> 
> Eike Ziller (6 November 2019 09:45)
>> It sounds to me like any automatically chosen base for 2-digit years
>> will be wrong depending on use case.
> 
> You (among several others) make a compelling case.
> 
>> 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 sounds like an excellent plan.
> I could even implement it in 5.15 as a new overload.
> 
> Simplest would be to have two optional arguments, startYear and span; in
> 5.15, startYear must be supplied (to distinguish this overload from the
> old method) but span can be optional, defaulting to 100 (also used if
> span < 0 or span > 100).  The old method will behave as if it were the
> new method with startYear = 1900, span = 100.  (We could specify endYear
> instead of span, but its default gets trickier.)  Two-digit years then
> get mapped to a year with startYear <= year < startYear + span.  If
> there is no such year with the given last digits, the field is treated
> as unparseable.  Using span=0 breaks short formats, but we can accept
> that as a deliberate choice some client code may make.

Not sure what usefulness span != 100 would have.

> There then remains the question of what the default should be in Qt 6
> (where we'll naturally unify the overloads).  If that's not 1900--1999,
> then we should deprecate the old method at 5.15 and encourage its
> callers to explicitly pass 1900 as startYear, if that's really what they
> want.  Sample options:
> * keep 1900-1999, discourage use of ShortFormat;
> * rolling window based on currentDate(), as I described earlier;
> * we update startYear's default with each major release of Qt.

Why would you change the default from what it is now?
A default that is changing in behavior, either automatically via currentDate, or “manually” with major releases, is creating surprises.
The least surprise is a clearly documented, fixed default behavior, with the obvious hint that the behavior should better be explicitly stated by the user of the function.
E.g. by changing the signature to

fromString(const QString &string, Qt::DateFormat format = Qt::TextDate, int startForTwoDigitYears = 1900)

> For the last, for example, we could make startYear=1940 in Qt6; by the
> time we get to a major release in the late '20s, we'd be ready to move
> that to startYear=1950.  I guess we can be confident of at least one
> major release per not much more than a decade, which suffices to ensure
> that dates throughout the supported life-time of that release do
> round-trip, while reaching well into the past.  That's assuming
> range=100: if we use a buffer zone, range=90 for example, we'd probably
> want Qt6 using startYear=1950 already (so '40s are invalid and '30s are
> the 2030s).
> 
> Any objections to this revised plan ?
> Anyone want to make the case for keeping 1900--1999 as default ?
> Or for my earlier dynamic floating-window proposal ?
> Or any other suggestions for the default ?
> If not, the update at major release - a.k.a. static floating-window -
> looks the sanest to me.
> 
> 	Eddy.

-- 
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