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, csrabak@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 <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================