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

[Edward Welbourne]

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.