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
Thanks david
Now I think that we could have
Date readFromTwoDigitYear:
or something like that.
And that Date readFromString: always reads a coherent 4 digits year.
This seems to have been more controversial than I expected. I'm going to
write this post in which I will:
, January 17, 2010 9:18 AM
To: pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Date fromString: '6-Jan-10'
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
@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Date fromString: '6-Jan-10'
Thanks david
Now I think that we could have
Date readFromTwoDigitYear:
or something like that.
And that Date readFromString: always reads a coherent 4 digits year.
This seems to have been more
El dom, 17-01-2010 a las 14:17 +, 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
Em 17/01/2010 12:17, David Hotham david.hot...@blueyonder.co.uk escreveu:
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
Quoting csra...@bol.com.br:
...
Python goes this way, for example.
- the date is assumed to be between 80 years in the past and 20
years inthe future (egJava's SimpleDateFormat, see
http://java.sun.com/javase/7/docs/api/java/text/SimpleDateFormat.html)
- allow
The real life situation with date strings is much worse.
I live in a city (Zoetermeer) where a passport was issued
with the holders birthdate being 00-00-1972.
I'm very much in favor of not trying to be clever in the
core Date classes, and to provide separate guessing logic,
properly
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of
dphar...@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 csra...@bol.com.br:
...
Python goes this way, for example
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:
don't know if this addresses your confusion:
before: '5-APR-10' got parsed as April 5, 1910
after: '5-APR-10' gets parsed as April 5, 2010
so it kind of fixes the passing of time :-)
This kind of cleverness should not be there, IMHO.
a) you want to parse special date formats: you should use
On Jan 16, 2010, at 11:07 AM, Matthias Berth wrote:
don't know if this addresses your confusion:
before: '5-APR-10' got parsed as April 5, 1910
after: '5-APR-10' gets parsed as April 5, 2010
so it kind of fixes the passing of time :-)
This kind of cleverness should not be there, IMHO.
Hello,
The motivation behind this fix is that I am parsing historical stock data
obtained from Google, in which dates are provided like this: 15-Jan-10.
Of course I want this to read as 2010, not 1910.
I agree that the existing solution (with or without my tweak) looks ugly.
I gave brief
no problem
we were not criticizing your fix more the problem in general
Would be nice to have a guessFrom:
Stef
On Jan 16, 2010, at 12:07 PM, David Hotham wrote:
Hello,
The motivation behind this fix is that I am parsing historical stock data
obtained from Google, in which dates are
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
Yes
Date fromString: '6-Jan-03'
- 6 January 2003
is also wrong. So david just tried to patch this wrong behavior.
Stef
On Jan 16, 2010, at 6:02 PM, 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
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
I think a solution that can tuned or tweaked to it's application would
be must useful. It's all very well to insist on users using four-
digit years, but for processing historical data, for example, one
doesn't have the luxury of insisting on the data format, but has to
use what is there
But if you deal with incomplete data why not building your own reader and
control
it. I think that a library class cannot be tuned to deal with all kind of crazy
situation.
I would prefer that Date is robust and consistent and that people implement
their own
custom situation.
Does anybody
: Re: [Pharo-project] Date fromString: '6-Jan-10'
But if you deal with incomplete data why not building your own reader and
control it. I think that a library class cannot be tuned to deal with all kind
of crazy situation.
I would prefer that Date is robust and consistent and that people implement
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
21 matches
Mail list logo
