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" <[email protected]> wrote in > message news:[email protected]... > > 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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
