André Somers (6 November 2019 17:20) wrote > I came to the conclusion that the sane behavior for interpreting dates > depends on the semantics of what the date means. For instance, a birth > date will always be a date in the past,
... except when it's the best-estimate date of birth of an expected child, or part of a discussion of how (say) an education system will handle the cohorts of children born in various date ranges. I'll agree, though, that birth dates are *usually* in the past ;^> Even when it is in the past, the range of past dates it may land in is more than a century wide. Some folk live for more than a century; and records of dates of birth of folk can be relevant even after the folk in question are dead. (All of which argues against using two-digit years in dates of birth, common though that practice is.) > while a date for an appointment would normally be a date in the > future. and usually not very far in the future, at that, which makes this one of the cases where two-digit years aren't automatically a bad idea. > That alters the interpretation of the date. May I suggest adding an > enum argument to any function doing the conversion from a string to a > date that allows you tell you to suggest the kind of date that is > expected? That would imply inventing (and documenting) how we're going to implement each member of the enum; and, fundamentally, that's going to boil down to specifying (per enum member) a range of (up to) 100 years that each two-digit year value gets mapped into. Then along comes some user whose use-case we didn't think of and we need to extend the enum and the enum grows endlessly. I think it is easier to let the caller just specify that year range (principally by its start date). The caller can then invent any flavour of year range they like. Eddy. _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development