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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of dpharris@telus.net Sent: Sunday, January 17, 2010 5:30 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Date fromString: '6-Jan-10' Quoting csrabak@bol.com.br:
...
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project