On 11/6/19 1:38 PM, Edward Welbourne wrote: > > Anyone want to make the case for keeping 1900--1999 as default ?
Yup, I'll bite, for the following reasons: 1) The downside of changing it is certain: breaking existing apps. In particular, breaking the old code dealing with old data, which is the parts nobody knows anymore or want to touch... 2) The upside is uncertain: as the discussion has shown, there are a lot of different ways to change it; whatever we choose will only match the expectations of a subset of users. The app developer will most likely end up having to deal with the issue explicitly anyway. 3) It will add to the industry confusion in an already dysfunctional field. "How will 2 digits be interpreted? Well, is the app Qt-based or not? Is it Qt 6 or earlier?" 4) At some point in the not too distant future, some standards organization or industry consensus may establish a "best practice" for this issue. At that point we must add support for that - and would rather not have to also maintain any home-invented alternative behaviour (for backwards compatibility), adding to the chaos. Just my 2c :) BTW, I also had the thought that just adding a parameter of type enum TwoDigitYearBase { EpochCentury, CurrentCentury } to the relevant apis would solve most common cases (with the default being EpochCentury, i.e. 1900) ? Although the suggested (startYear, span) api is certainly also useful for more complex usecases. - Eirik Aa. _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development