[Glass] Comment of #newDay:monthNumber:year: is wrong (and I do not like the behavior either!)

[Mariano Martinez Peck via Glass]

Hi Dale and others,

The Smalltalk fix is not possible to put in Date class
#newDay:monthNumber:year:  (which is the ideal place) because since the
primitive does NOT fail, then the smalltalk code below is never executed.
Therefore, the fix must be at the sender of this guy. Unfortunately, there
are a few :(

The "fix" I propose is the following. Please let me know if this looks
correct:

New helper method:

*Date class >> numberOfDaysIn: month year: aYear*

((month == 1) or: [(month == 3) or: [(month == 5) or: [(month == 7) or:
   [(month == 8) or: [(month == 10) or: [(month == 12)]]]]]])
   ifTrue: [^ 31].
((month == 4) or: [(month == 6) or: [(month == 9) or: [(month == 11)]]])
   ifTrue: [^ 30].
(((aYear \\ 100) == 0)
   ifTrue: [ ((aYear \\ 400) == 0)]
   ifFalse: [ ((aYear \\ 4) == 0) ])
  ifTrue: [^ 29].
^ 28


And then, change each sender of #newDay:monthNumber:year:  to add the 2
lines below:

Date class >> year: year month: month day: day
* (month between: 1 and: 12) ifFalse: [ self error: 'Incorrect specified
month: ', month asString].*
* (day between: 1 and: (self numberOfDaysIn: month year: year)) ifFalse: [
self error: 'Incorrect specified day: ', day asString]. *

^self newDay: day monthNumber: month year: year

Does it look correct to you?

Best,





On Fri, Aug 7, 2015 at 5:24 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> Mariano,
>
> Since the creation of a date is a primitive call, the official fix will be
> in C code (I think) ...  it looks like there is no validation for the day
> of the month, so a straight forward Smalltalk patch should be possible ...
>
> Dale
>
>
> On 08/07/2015 01:18 PM, Mariano Martinez Peck wrote:
>
> Thanks Dale. If a back port or workaround is easy for 3.1.0.7 I would
> appreciate that too.... I don't expext an official release... but maybe a
> workaround. I do not even care if I have to put it as an override as part
> of my packages... Of course...I can write myself the validation of ranges
> too...
> But seems to me it sounds like a big bug... all users of such a method
> could have been getting a shifted date if they did not send a correct one...
>
> On Fri, Aug 7, 2015 at 5:10 PM, Dale Henrichs via Glass <
> glass at lists.gemtalksystems.com> wrote:
>
>> Mariano,
>>
>> Thanks for the report, I've submitted an internal bug (45525) on this
>> against 3.2.7 and 3.3.
>>
>> Dale
>>
>>
>> On 08/07/2015 06:35 AM, Mariano Martinez Peck via Glass wrote:
>>
>> Hi guys,
>>
>> Just for the record, the comment of:
>>
>> Date class >> newDay: day monthNumber: month year: year
>>
>> *"*Creates and returns an instance of the receiver from the specified
>> values.
>> * Generates an error if any of the values are out of range."*
>>
>> Is wrong since it does not throws and error and instead shifts the day.
>> Example:
>>
>> Date newDay: 31 monthNumber: 6 year: 2015   -> 07/01/2015   (June has
>> only 30 days)
>>
>> BTW... This is a frustrating behavior for me. Pharo would correctly throw
>> a DateError, but GemStone shifts and gives me back another date. This could
>> lead to problems quite hard to debug.
>>
>> Cheers,
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>>
>> _______________________________________________
>> Glass mailing listGlass at lists.gemtalksystems.comhttp://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>>
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150810/f8cb7c1e/attachment-0001.html>