Quoting [email protected]: > ... > > Python goes this way, for example. > > > - the date is assumed to be between 80 years in the past and 20 > > years in the future (eg Java's SimpleDateFormat, see > > http://java.sun.com/javase/7/docs/api/java/text/SimpleDateFormat.html) > > - allow the 100 year-period in which 2-digit years will be placed > > to be specified (eg the Java SimpleDateFormat also allows this) > > > > This an interesting advantage (at first) that uses some moving epoch > to compute the century, but has IMNHO a terrific disadvantage: it will > break unit tests as soon your code crosses the boundary of ten years > period (like some code done last year and tested in 2011).
I think this is a *sliding* period: 80 years before the *current* year, and 20 years into the future from the *current* year. So, presently this would be from 1911 to 2030, next year it would be 1912-2031. I would suspect this would cover most uses, and is easy to specify. (Birth dates might be a common exception. ) I agree that using 4-digit years is best for user input. David _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
