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.
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.
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.
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
