El dom, 17-01-2010 a las 14:17 +0000, David Hotham escribió:
This seems to have been more controversial than I expected. I'm going to write this post in which I will:
- try to make the case for supporting 2-digit years in some sensible way - answer some of the counter-arguments and questions that people have raised
... at which point I intend to withdraw, and the community will no doubt reach some sensible conclusion.
David
The case for accepting 2-digit years is, I think, very simple: it's useful. Like it or not, data sometimes comes that way and this has to be dealt with.
Yes, but it can be handled in your code, by first massaging the legacy input data and then, after is 4 digits, passing it to the smalltalk code. This way the core library doesn't get dirty with special cases and your app works correctly. So first correct your input and then proccess it. Just like a web app. Don't assume the input data is ok. Cheers
Granted, this means that we have to introduce some heuristic to guess which century is intended. However, I don't see that this is so bad. Amongst the possible approaches are:
- Following the Posix standard for strptime, the date is assumed to be between 1969 and 2068 (see http://www.opengroup.org/onlinepubs/009695399/functions/strptime.html). 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)
Now I will address some concerns that people have raised.
The first is essentially aesthetic: this kind of cleverness should not be there, and everyone should always use four-digit years. I've some sympathy with this, and it would be wonderful if everyone was as principled as we are. But, alas, it is not so! My judgment is that it's worth a little ugliness to be able to deal with the common case of two-digit years.
A second objection was that the code was right all along: '6-Jan-10' should correctly be parsed as 6th January 1910. This seems to me peculiar. I understand a position that says that two-digit years should not be accepted at all, but arguing that they should be accepted and should be interpreted to be 100 or more years ago... well, this seems unlikely to be the most useful approach.
A third objection was that this is the thin end of the wedge: if we start accepting two-digit years, who knows where the madness will end? We will have to deal with all kinds of crazy situation!
I think that this objection is just wrong. Noone is arguing for three-digit dates, or hexadecimal dates, or any other crazy stuff. Two-digits are commonplace. Other crazy things are not commonplace. Let's draw the line where it makes sense to draw the line: to my mind handling two-digit years clearly falls on the 'useful' side and not the 'crazy' side.
Finally, I must note the irony of one poster declaring that we should only accept well-formed strings, and pointing us at RFC822 for reference. Years in RFC822 are defined to have two digits. The RFC does not say what century they should fall in. (This has been obsoleted by RFC2822, which uses four-digit years).
"Stéphane Ducasse" <stephane.ducasse@inria.fr> wrote in message news:78E0F3D1-D169-43D9-B12E-6C9D4E2860C5@inria.fr...
hi guys
can one of you give a look at the this fix because I'm confused. Kernel-DavidHotham.538
year < 20 ifTrue: [year := 2000 + year] was year < 10 ifTrue: [year := 2000 + year]
both solutions look strange to me.
http://code.google.com/p/pharo/issues/detail?id=1749
readFrom: aStream "Read a Date from the stream in any of the forms: <day> <monthName> <year> (5 April 1982; 5-APR-82) <monthName> <day> <year> (April 5, 1982) <monthNumber> <day> <year> (4/5/82) <day><monthName><year> (5APR82)" | day month year | aStream peek isDigit ifTrue: [day := Integer readFrom: aStream]. [aStream peek isAlphaNumeric] whileFalse: [aStream skip: 1]. aStream peek isLetter ifTrue: ["number/name... or name..." month := (String new: 10) writeStream. [aStream peek isLetter] whileTrue: [month nextPut: aStream next]. month := month contents. day isNil ifTrue: ["name/number..." [aStream peek isAlphaNumeric] whileFalse: [aStream skip: 1]. day := Integer readFrom: aStream]] ifFalse: ["number/number..." month := Month nameOfMonth: day. day := Integer readFrom: aStream]. [aStream peek isAlphaNumeric] whileFalse: [aStream skip: 1]. year := Integer readFrom: aStream.
year < 20 ifTrue: [year := 2000 + year] ifFalse: [ year < 1900 ifTrue: [ year := 1900 + year]].
^ self year: year month: month day: day
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx