Expectation for readFrom:... getting bored to fix bugs.
Locked
Expectation for readFrom:... getting bored to fix bugs.
 
|
Hi
What are the expectation for DateAndTime>>readFrom? On squeak such tests do not pass. testReadFromFoolProofExtension "Convenient extension without a time, only a date" "self debug: #testReadFromFoolProofExtension" self assert: ('2008' asDateAndTime printString = '2008-01-01T00:00:00+00:00'). self assert: ('2008-08' asDateAndTime printString = '2008-08-01T00:00:00+00:00'). self assert: ('2006-08-28' asDateAndTime printString = '2006-08-28T00:00:00+00:00'). "Regular nanoseconds" self assert: ('2006-08-28T00:00:00.123456789' asDateAndTime printString = '2006-08-28T00:00:00.123456789+00:00'). "Extra picoseconds precision should not spoil the DateAndTime" self assert: ('2006-08-28T00:00:00.123456789000' asDateAndTime printString = '2006-08-28T00:00:00.123456789+00:00'). in Pharo DateAndTime>>rreadFrom: aStream | bc year month day hour minute second nanos offset buffer ch | aStream peek = $- ifTrue: [ aStream next. bc := -1] ifFalse: [bc := 1]. year := (aStream upTo: $-) asInteger * bc. month := (aStream upTo: $-) asInteger ifNil: [1]. day := (aStream upTo: $T) asInteger ifNil: [1]. hour := (aStream upTo: $:) asInteger ifNil: [0]. buffer := '00:' copy. ch := nil. minute := buffer writeStream. [ aStream atEnd | (ch = $:) | (ch = $+) | (ch = $-) ] whileFalse: [ ch := minute nextPut: aStream next. ]. (ch isNil or: [ch isDigit]) ifTrue: [ ch := $: ]. minute := (buffer readStream upTo: ch) asInteger. buffer := '00.' copy. second := buffer writeStream. [ aStream atEnd | (ch = $.) | (ch = $+) | (ch = $-) ] whileFalse: [ ch := second nextPut: aStream next. ]. (ch isNil or: [ch isDigit]) ifTrue: [ ch := $. ]. second := (buffer readStream upTo: ch) asInteger. buffer := '000000000' copy. (ch = $.) ifTrue: [ nanos := buffer writeStream. [ aStream atEnd | ((ch := aStream next) = $+) | (ch = $-) ] whileFalse: [ nanos nextPut: ch. ]. (ch isNil or: [ch isDigit]) ifTrue: [ ch := $+ ]. ]. nanos := buffer asInteger. aStream atEnd ifTrue: [ offset := Duration zero ] ifFalse: [ch := aStream next. ch = $+ ifTrue: [ch := Character space]. offset := Duration fromString: ch asString, '0:', aStream upToEnd, ':0']. ^ self year: year month: month day: day hour: hour minute: minute second: second nanoSecond: nanos offset: offset. It loosk a bit ugly and crashed on some inputs In Squeak they have code that looks cleaner readFrom: aStream | offset date time ch | date := Date readFrom: aStream. [aStream peek isDigit] whileFalse: [aStream next]. time := Time readFrom: aStream. aStream atEnd ifTrue: [ offset := Duration zero ] ifFalse: [ ch := aStream next. ch = $+ ifTrue: [ch := Character space]. offset := Duration fromString: ch asString, '0:', aStream upToEnd, ':0']. ^ self year: date year month: date monthIndex day: date dayOfMonth hour: time hour minute: time minute second: time second nanoSecond: time nanoSecond offset: offset Date ============================================================ For Date we have readFrom: aStream readFrom: pattern: "Read a Date from the stream in any of the forms: <day> <month> <year> (15 April 1982; 15-APR-82; 15.4.82; 15APR82) <month> <day> <year> (April 15, 1982; 4/15/82) Squeak has a better one readFrom: pattern: "Read a Date from the stream in any of the forms: <day> <month> <year> (15 April 1982; 15-APR-82; 15.4.82; 15APR82) <month> <day> <year> (April 15, 1982; 4/15/82) <year>-<month>-<day> (1982-04-15) (ISO8601)" I like the idea to have a readFrom: that is parsing a specific input and that the variations are handled in separate methods. So for DateAndTime we coudl have fuzzyReadFrom: aStream or something like that. Duration ====================================================== Now for Duration readFrom: the pattern is strictly followed "Formatted as per ANSI 5.8.2.16: [-]D:HH:MM:SS[.S]" In pharo it was bogus. So I was considering the one of Squeak, which looks cleaner. Pharo broke for (Duration readFrom: '0:00:00:00.001 ' readStream) nanoSeconds Squeak>>readFrom: aStream "Formatted as per ANSI 5.8.2.16: [-]D:HH:MM:SS[.S]" | sign days hours minutes seconds nanos nanosBuffer | sign := (aStream peekFor: $-) ifTrue: [-1] ifFalse: [1]. days := (aStream upTo: $:) asInteger sign: sign. hours := (aStream upTo: $:) asInteger sign: sign. minutes := (aStream upTo: $:) asInteger sign: sign. seconds := (aStream upTo: $.) asInteger sign: sign. nanosBuffer := '000000000' copy. nanos := WriteStream on: nanosBuffer. [aStream atEnd not and: [aStream peek isDigit]] whileTrue: [nanos nextPut: aStream next]. ^ self days: days hours: hours minutes: minutes seconds: seconds nanoSeconds: (nanosBuffer asInteger sign: sign) Pharo>>readFrom: aStream "Formatted as per ANSI 5.8.2.16: [-]D:HH:MM:SS[.S] To assiste DateAndTime>>#readFrom: SS may be unpadded or absent." | sign days hours minutes seconds nanos ws ch | sign := (aStream peekFor: $-) ifTrue: [-1] ifFalse: [1]. days := (aStream upTo: $:) asInteger sign: sign. hours := (aStream upTo: $:) asInteger sign: sign. minutes := (aStream upTo: $:) asInteger sign: sign. aStream atEnd ifTrue: [seconds := 0. nanos := 0] ifFalse: [ ws := String new writeStream. [ch := aStream next. (ch isNil) | (ch = $.)] whileFalse: [ ws nextPut: ch ]. seconds := ws contents asInteger sign: sign. ws reset. 9 timesRepeat: [ ch := aStream next. ws nextPut: (ch ifNil: [$0] ifNotNil: [ch]) ]. nanos := ws contents asInteger sign: sign]. ^ self days: days hours: hours minutes: minutes seconds: seconds nanoSeconds: nanos. ====================================================== Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Expectation for readFrom:... getting bored to fix bugs.
|
|
On Sat, Apr 24, 2010 at 10:54 AM, stephane ducasse <[hidden email]> wrote:
What are the expectation for DateAndTime>>readFrom? Personally, my expectation is that it doesn't exist. :) To believe that there is a single way of parsing strings into dates (or numbers, or anything else) that will be appropriate in all cases is pretty silly. It would seem much better to me to have configurable parsing classes. Julian _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Expectation for readFrom:... getting bored to fix bugs.
|
|
2010/4/24 Julian Fitzell <[hidden email]>:
> On Sat, Apr 24, 2010 at 10:54 AM, stephane ducasse > <[hidden email]> wrote: >> >> What are the expectation for DateAndTime>>readFrom? > > Personally, my expectation is that it doesn't exist. :) > > To believe that there is a single way of parsing strings into dates (or > numbers, or anything else) that will be appropriate in all cases is pretty > silly. It would seem much better to me to have configurable parsing classes. > > Julian > Sure, that might be usefull, however current implementation intention clearly seems related to http://en.wikipedia.org/wiki/ISO_8601 Nicolas > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Expectation for readFrom:... getting bored to fix bugs.
|
|
In reply to this post by Julian Fitzell-2
yes but before having that and all the complexity it can bring I suggest to stick with a non fuzzy and customizable
parser that does not exist yet and stick to ISO format and parse only this one but well. Stef On Apr 24, 2010, at 9:16 PM, Julian Fitzell wrote: > On Sat, Apr 24, 2010 at 10:54 AM, stephane ducasse <[hidden email]> wrote: > What are the expectation for DateAndTime>>readFrom? > > Personally, my expectation is that it doesn't exist. :) > > To believe that there is a single way of parsing strings into dates (or numbers, or anything else) that will be appropriate in all cases is pretty silly. It would seem much better to me to have configurable parsing classes. > > Julian > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Expectation for readFrom:... getting bored to fix bugs.
|
|
In reply to this post by Nicolas Cellier
What I did was to stick with the ISO parsing and added a fuzzy readfrom (the previous one in pharo)
so that readFrom: read only iso but well and fuzzy tries to find its way with strange input. Stef On Apr 24, 2010, at 9:48 PM, Nicolas Cellier wrote: > 2010/4/24 Julian Fitzell <[hidden email]>: >> On Sat, Apr 24, 2010 at 10:54 AM, stephane ducasse >> <[hidden email]> wrote: >>> >>> What are the expectation for DateAndTime>>readFrom? >> >> Personally, my expectation is that it doesn't exist. :) >> >> To believe that there is a single way of parsing strings into dates (or >> numbers, or anything else) that will be appropriate in all cases is pretty >> silly. It would seem much better to me to have configurable parsing classes. >> >> Julian >> > > Sure, that might be usefull, however current implementation intention > clearly seems related to > http://en.wikipedia.org/wiki/ISO_8601 > > Nicolas > >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Nicolas Cellier
Then a more appropriate class would be ISO8601DateAndTime for this method to remain in Pharo? -- Cesar Rabak Em 24/04/2010 16:48, Nicolas Cellier < [hidden email] > escreveu: 2010/4/24 Julian Fitzell : > On Sat, Apr 24, 2010 at 10:54 AM, stephane ducasse > wrote: >> >> What are the expectation for DateAndTime>>readFrom? > > Personally, my expectation is that it doesn't exist. :) > > To believe that there is a single way of parsing strings into dates (or > numbers, or anything else) that will be appropriate in all cases is pretty > silly. It would seem much better to me to have configurable parsing classes. > > Julian > Sure, that might be usefull, however current implementation intention clearly seems related to http://en.wikipedia.org/wiki/ISO_8601 Nicolas > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Expectation for readFrom:... getting bored to fix bugs.
|
|
In reply to this post by Stéphane Ducasse
imo, it should look like:
readFrom: stream ^ readFrom: stream pattern: ISO8601 and readFrom:pattern: should parse date by taking an arbitrary pattern into account. We could invent own syntax for a pattern, or use other invented ones (from C, Perl etc), and implement a separate DateTimeParser class. The messy code like this aStream peek = $- ifTrue: [ aStream next. bc := -1] ifFalse: [bc := 1]. year := (aStream upTo: $-) asInteger * bc. month := (aStream upTo: $-) asInteger ifNil: [1]. day := (aStream upTo: $T) asInteger ifNil: [1]. hour := (aStream upTo: $:) asInteger ifNil: [0]. should be put in trash! :) On 24 April 2010 23:05, Stéphane Ducasse <[hidden email]> wrote: > What I did was to stick with the ISO parsing and added a fuzzy readfrom (the previous one in pharo) > so that readFrom: read only iso but well and fuzzy tries to find its way with strange input. > > Stef > > On Apr 24, 2010, at 9:48 PM, Nicolas Cellier wrote: > >> 2010/4/24 Julian Fitzell <[hidden email]>: >>> On Sat, Apr 24, 2010 at 10:54 AM, stephane ducasse >>> <[hidden email]> wrote: >>>> >>>> What are the expectation for DateAndTime>>readFrom? >>> >>> Personally, my expectation is that it doesn't exist. :) >>> >>> To believe that there is a single way of parsing strings into dates (or >>> numbers, or anything else) that will be appropriate in all cases is pretty >>> silly. It would seem much better to me to have configurable parsing classes. >>> >>> Julian >>> >> >> Sure, that might be usefull, however current implementation intention >> clearly seems related to >> http://en.wikipedia.org/wiki/ISO_8601 >> >> Nicolas >> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Expectation for readFrom:... getting bored to fix bugs.
|
|
Yes!!!!
Right now I will keep readFrom: (reading only ISO8601) and if one day we get what you propose I would be happy. Send code :) > imo, it should look like: > > readFrom: stream > ^ readFrom: stream pattern: ISO8601 > > and > readFrom:pattern: > > should parse date by taking an arbitrary pattern into account. > We could invent own syntax for a pattern, or use other invented ones > (from C, Perl etc), > and implement a separate DateTimeParser class. > > The messy code like this > aStream peek = $- ifTrue: [ aStream next. bc := -1] ifFalse: [bc := 1]. > year := (aStream upTo: $-) asInteger * bc. > month := (aStream upTo: $-) asInteger ifNil: [1]. > day := (aStream upTo: $T) asInteger ifNil: [1]. > hour := (aStream upTo: $:) asInteger ifNil: [0]. > > should be put in trash! :) > > On 24 April 2010 23:05, Stéphane Ducasse <[hidden email]> wrote: >> What I did was to stick with the ISO parsing and added a fuzzy readfrom (the previous one in pharo) >> so that readFrom: read only iso but well and fuzzy tries to find its way with strange input. >> >> Stef >> >> On Apr 24, 2010, at 9:48 PM, Nicolas Cellier wrote: >> >>> 2010/4/24 Julian Fitzell <[hidden email]>: >>>> On Sat, Apr 24, 2010 at 10:54 AM, stephane ducasse >>>> <[hidden email]> wrote: >>>>> >>>>> What are the expectation for DateAndTime>>readFrom? >>>> >>>> Personally, my expectation is that it doesn't exist. :) >>>> >>>> To believe that there is a single way of parsing strings into dates (or >>>> numbers, or anything else) that will be appropriate in all cases is pretty >>>> silly. It would seem much better to me to have configurable parsing classes. >>>> >>>> Julian >>>> >>> >>> Sure, that might be usefull, however current implementation intention >>> clearly seems related to >>> http://en.wikipedia.org/wiki/ISO_8601 >>> >>> Nicolas >>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Expectation for readFrom:... getting bored to fix bugs.
|
|
On 25 April 2010 10:12, Stéphane Ducasse <[hidden email]> wrote:
> Yes!!!! > Right now I will keep readFrom: (reading only ISO8601) and if one day we get > what you propose I would be happy. > Send code :) > Add it to issue tracker and CC to me :) I can't do it right now, since i'm currently busy with my NativeBoost project. >> imo, it should look like: >> >> readFrom: stream >> ^ readFrom: stream pattern: ISO8601 >> >> and >> readFrom:pattern: >> >> should parse date by taking an arbitrary pattern into account. >> We could invent own syntax for a pattern, or use other invented ones >> (from C, Perl etc), >> and implement a separate DateTimeParser class. >> >> The messy code like this >> aStream peek = $- ifTrue: [ aStream next. bc := -1] ifFalse: [bc := 1]. >> year := (aStream upTo: $-) asInteger * bc. >> month := (aStream upTo: $-) asInteger ifNil: [1]. >> day := (aStream upTo: $T) asInteger ifNil: [1]. >> hour := (aStream upTo: $:) asInteger ifNil: [0]. >> >> should be put in trash! :) >> >> On 24 April 2010 23:05, Stéphane Ducasse <[hidden email]> wrote: >>> What I did was to stick with the ISO parsing and added a fuzzy readfrom (the previous one in pharo) >>> so that readFrom: read only iso but well and fuzzy tries to find its way with strange input. >>> >>> Stef >>> >>> On Apr 24, 2010, at 9:48 PM, Nicolas Cellier wrote: >>> >>>> 2010/4/24 Julian Fitzell <[hidden email]>: >>>>> On Sat, Apr 24, 2010 at 10:54 AM, stephane ducasse >>>>> <[hidden email]> wrote: >>>>>> >>>>>> What are the expectation for DateAndTime>>readFrom? >>>>> >>>>> Personally, my expectation is that it doesn't exist. :) >>>>> >>>>> To believe that there is a single way of parsing strings into dates (or >>>>> numbers, or anything else) that will be appropriate in all cases is pretty >>>>> silly. It would seem much better to me to have configurable parsing classes. >>>>> >>>>> Julian >>>>> >>>> >>>> Sure, that might be usefull, however current implementation intention >>>> clearly seems related to >>>> http://en.wikipedia.org/wiki/ISO_8601 >>>> >>>> Nicolas >>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Expectation for readFrom:... getting bored to fix bugs.
|
|
In reply to this post by Igor Stasenko
2010/4/25 Igor Stasenko <[hidden email]>:
> imo, it should look like: > > readFrom: stream > ^ readFrom: stream pattern: ISO8601 > > and > readFrom:pattern: > Yes, and next step will be to optimize with a pre-compiled pattern (may use a cache). Otherwise, when you have a bunch of String to convert in DateAndTime, you're spending time in parsing the same pattern repeatedly. Nicolas > should parse date by taking an arbitrary pattern into account. > We could invent own syntax for a pattern, or use other invented ones > (from C, Perl etc), > and implement a separate DateTimeParser class. > > The messy code like this > aStream peek = $- ifTrue: [ aStream next. bc := -1] ifFalse: [bc := 1]. > year := (aStream upTo: $-) asInteger * bc. > month := (aStream upTo: $-) asInteger ifNil: [1]. > day := (aStream upTo: $T) asInteger ifNil: [1]. > hour := (aStream upTo: $:) asInteger ifNil: [0]. > > should be put in trash! :) > > On 24 April 2010 23:05, Stéphane Ducasse <[hidden email]> wrote: >> What I did was to stick with the ISO parsing and added a fuzzy readfrom (the previous one in pharo) >> so that readFrom: read only iso but well and fuzzy tries to find its way with strange input. >> >> Stef >> >> On Apr 24, 2010, at 9:48 PM, Nicolas Cellier wrote: >> >>> 2010/4/24 Julian Fitzell <[hidden email]>: >>>> On Sat, Apr 24, 2010 at 10:54 AM, stephane ducasse >>>> <[hidden email]> wrote: >>>>> >>>>> What are the expectation for DateAndTime>>readFrom? >>>> >>>> Personally, my expectation is that it doesn't exist. :) >>>> >>>> To believe that there is a single way of parsing strings into dates (or >>>> numbers, or anything else) that will be appropriate in all cases is pretty >>>> silly. It would seem much better to me to have configurable parsing classes. >>>> >>>> Julian >>>> >>> >>> Sure, that might be usefull, however current implementation intention >>> clearly seems related to >>> http://en.wikipedia.org/wiki/ISO_8601 >>> >>> Nicolas >>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Expectation for readFrom:... getting bored to fix bugs.
|
|
On 25 April 2010 10:45, Nicolas Cellier
<[hidden email]> wrote: > 2010/4/25 Igor Stasenko <[hidden email]>: >> imo, it should look like: >> >> readFrom: stream >> ^ readFrom: stream pattern: ISO8601 >> >> and >> readFrom:pattern: >> > > Yes, and next step will be to optimize with a pre-compiled pattern > (may use a cache). > Otherwise, when you have a bunch of String to convert in DateAndTime, > you're spending time in parsing the same pattern repeatedly. > Sure... piece of cake: ISO8601 := DateTimePattern compileFrom: 'xyz...[]./s]wefj..' And readFrom:pattern: could check that: compiledPattern := pattern isString ifFalse: [ pattern] ifTrue: [ DateTimePattern compileFrom: pattern ]. > Nicolas > >> should parse date by taking an arbitrary pattern into account. >> We could invent own syntax for a pattern, or use other invented ones >> (from C, Perl etc), >> and implement a separate DateTimeParser class. >> >> The messy code like this >> aStream peek = $- ifTrue: [ aStream next. bc := -1] ifFalse: [bc := 1]. >> year := (aStream upTo: $-) asInteger * bc. >> month := (aStream upTo: $-) asInteger ifNil: [1]. >> day := (aStream upTo: $T) asInteger ifNil: [1]. >> hour := (aStream upTo: $:) asInteger ifNil: [0]. >> >> should be put in trash! :) >> >> On 24 April 2010 23:05, Stéphane Ducasse <[hidden email]> wrote: >>> What I did was to stick with the ISO parsing and added a fuzzy readfrom (the previous one in pharo) >>> so that readFrom: read only iso but well and fuzzy tries to find its way with strange input. >>> >>> Stef >>> >>> On Apr 24, 2010, at 9:48 PM, Nicolas Cellier wrote: >>> >>>> 2010/4/24 Julian Fitzell <[hidden email]>: >>>>> On Sat, Apr 24, 2010 at 10:54 AM, stephane ducasse >>>>> <[hidden email]> wrote: >>>>>> >>>>>> What are the expectation for DateAndTime>>readFrom? >>>>> >>>>> Personally, my expectation is that it doesn't exist. :) >>>>> >>>>> To believe that there is a single way of parsing strings into dates (or >>>>> numbers, or anything else) that will be appropriate in all cases is pretty >>>>> silly. It would seem much better to me to have configurable parsing classes. >>>>> >>>>> Julian >>>>> >>>> >>>> Sure, that might be usefull, however current implementation intention >>>> clearly seems related to >>>> http://en.wikipedia.org/wiki/ISO_8601 >>>> >>>> Nicolas >>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |