80/20 is probably not unreasonable, but it cannot be based on the current date - it has to be based on the date the entry occurred. In short, it has to be specified separately; even then, it's still just a guess.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Sunday, January 17, 2010 5:30 PM To: [email protected] Subject: Re: [Pharo-project] Date fromString: '6-Jan-10' 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.htm > > l) > > - 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
