All these cases only reinforce IMNSHO that the specific 'user' (in fact programmer) input/data entry/conversion routine should be responsible for the critique of the string and we should accept only well formed strings (some standards exist, like RFC-822).
Otherwise we'll end up with a lot of quasi similar methods each slightly different to accommodate some very specific need and the effort to document and maintain this will grow bigger than our resources. my 0.001999 -- Cesar Rabak Em 16/01/2010 18:09, John M McIntosh < john...@smalltalkconsulting.com > escreveu: Well oddly I encounter a simular issue on the iPhone the other week when dealing with Apple's Date Scanner logic. It seems that if a person entered 1/1/09 that would generate jan 1st, 2009. but 1/1/9 would generate jan 1st, year 1 AD I recalling read a novel set in 1715 where they talked about the year 3, meaning 1703 not 3 AD. But I can't recall anyone this millennium using year 9 to refer to 2009 although they might tap that into a entry field. I note you *must* in this case separate the *correct* way of thinking to the *common mostly correct* way of thinking. Most people you met in the USA would think that 1/1/09 means 2009, NOT 1909. Obviously for fields that *could be* a date that could be > 100 years you would have to enforce four digit years, or something, but defaulting to 1909 versus 2009 might have interesting side-effects. Also expiry date 2014 as 1/1/14 this is not assumed to be 1914. On 2010-01-16, at 9:02 AM, csra...@bol.com.br wrote: > I'm afraid the 'fix' is trying to repair something is not broken! > > Date fromString: '6-Jan-10'. giving "6 January 1910" has not anything wrong. > Within five year we'll have users/programmers complaining that: > > Date fromString: '6-Jan-16'. gave "6 January 1916" and *obviously* it should > have given "6 January 2015"!! > > Rather document that years given with two figures get counted from 1900 (as > it used to be in last century) and have people to use four digits for years > in the 2000s. > > Otherwise: > > 1) We need to get used to the concept of an epoch time for Pharo; or > > 2) the number to be tested has to be the current year! > > My 0.019999. . . > > -- > Cesar Rabak > > -- =========================================================================== John M. McIntosh Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
