Re: [Oorexx-devel] Recent changes in DateTime class?

[Mike Cowlishaw]

 

And today is also 1st October but this time the method worked :-) 
 

:-)) 
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Recent changes in DateTime class?

[P.O. Jonsson]

And today is also 1st October but this time the method worked :-)

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se




> Am 01.10.2019 um 16:43 schrieb Mike Cowlishaw :
> 
> Reminds me of a 1st October many years ago, when a cleanup of code for the 
> Date function in classic Rexx (by Steve D) broke on 1 October all over the 
> corporation ...
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Recent changes in DateTime class?

[P.O. Jonsson]

OK, thanks for the info, I have updated the test case accordingly.

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se




> Am 01.10.2019 um 13:21 schrieb Rick McGuire :
> 
> This was a change for bug 1633. The original implementation seriously missed 
> the mark on both how the timezone should be interpreted when parsing the ISO 
> format and also the syntax of the format itself.
> 
> Rick
> 
> On Tue, Oct 1, 2019 at 6:28 AM P.O. Jonsson  > wrote:
> Dear developers,
> 
> I had a failure in the test of the timezone.rexx sample:
> 
> [failure] [20191001 11:38:33.555429]
>   svn:runknown   Change date: unknown  
>   Test:   TEST_04_TIMEZONE.REX
>   Class:  timezone.testGroup
>   File:   .../ooRexx/samples/timezone.testGroup
>   Line:   155
>   Failed: assertEquals
> Expected: [[Original date: 2009-03-08T00:30:00.00-0500], 
> identityHash="-4560494593"]
> Actual:   [[Original date: 2009-03-07T19:30:00.00-05:00], 
> identityHash="-4551321553"]
> 
> There are two differences compared to the past (I only ran the samples tests 
> some months ago):
> 
> 0500 changed to 05:00
> 08T00:30 changed to 07T19:30
> 
> The line in timezone.rex where it fails is:
> 
>   say 'Original date:' finalTime~utcIsoDate
> 
> finalTime is an instance of the DateTime class
> 
> When I looked at the latest rexxreff.pdf it states for the method utcIsoDate:
> 
> Returns the timestamp formatted as a string in ISO timezone-qualified date 
> format. If the timezone offiset is 0, the format is 
> -mm-ddThh:mm:ss.uuZ. If the offset is positive, the string is 
> formatted as -mm-ddThh:mm:ss.uu+hhmm. If the offset is negative, the 
> result will be in the format -mm-ddThh:mm:ss.uu-hhmm.
> 
> The current output is thus not consistent with the documentation.
> 
> Shall I report this as a bug or can you take it from here? The first change 
> is merely formal but the 2nd one I am not sure how to interpret.
> 
> The testcases for all the samples were offered in March this year and can be 
> found here:
> 
> https://www.dropbox.com/sh/p66c7g01h4jz5ss/AAAZd_Q2yQddrTHagxPo_UiTa?dl=0 
> 
> 
> PS good news is that all other samples test cases worked fine :-)
> 
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se 
> 
> 
> 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Recent changes in DateTime class?

[Mike Cowlishaw]

Reminds me of a 1st October many years ago, when a cleanup of code for the
Date function in classic Rexx (by Steve D) broke on 1 October all over the
corporation ...
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Recent changes in DateTime class?

[Rick McGuire]

This was a change for bug 1633. The original implementation seriously
missed the mark on both how the timezone should be interpreted when parsing
the ISO format and also the syntax of the format itself.

Rick

On Tue, Oct 1, 2019 at 6:28 AM P.O. Jonsson  wrote:

> Dear developers,
>
> I had a failure in the test of the timezone.rexx sample:
>
> [failure] [20191001 11:38:33.555429]
>   svn:runknown   Change date: unknown
>   Test:   TEST_04_TIMEZONE.REX
>   Class:  timezone.testGroup
>   File:   .../ooRexx/samples/timezone.testGroup
>   Line:   155
>   Failed: assertEquals
> Expected: [[Original date: 2009-03-08T00:30:00.00-0500],
> identityHash="-4560494593"]
> Actual:   [[Original date: 2009-03-07T19:30:00.00-05:00],
> identityHash="-4551321553"]
>
> There are two differences compared to the past (I only ran the samples
> tests some months ago):
>
> 0500 changed to 05:00
> 08T00:30 changed to 07T19:30
>
> The line in timezone.rex where it fails is:
>
> *  say 'Original date:' finalTime~utcIsoDate*
>
> finalTime is an instance of the DateTime class
>
> When I looked at the latest rexxreff.pdf it states for the method
> utcIsoDate:
>
> *Returns the timestamp formatted as a string in ISO timezone-qualified
> date format. If the timezone offiset is 0, the format is
> -mm-ddThh:mm:ss.uuZ. If the offset is positive, the string is
> formatted as -mm-ddThh:mm:ss.uu+hhmm. If the offset is negative,
> the result will be in the format -mm-ddThh:mm:ss.uu-hhmm.*
>
> The current output is thus not consistent with the documentation.
>
> Shall I report this as a bug or can you take it from here? The first
> change is merely formal but the 2nd one I am not sure how to interpret.
>
> The testcases for all the samples were offered in March this year and can
> be found here:
>
> https://www.dropbox.com/sh/p66c7g01h4jz5ss/AAAZd_Q2yQddrTHagxPo_UiTa?dl=0
>
> PS good news is that all other samples test cases worked fine :-)
>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
>
>
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Recent changes in DateTime class?

[P.O. Jonsson]

Dear developers,

I had a failure in the test of the timezone.rexx sample:

[failure] [20191001 11:38:33.555429]
  svn:runknown   Change date: unknown  
  Test:   TEST_04_TIMEZONE.REX
  Class:  timezone.testGroup
  File:   .../ooRexx/samples/timezone.testGroup
  Line:   155
  Failed: assertEquals
Expected: [[Original date: 2009-03-08T00:30:00.00-0500], 
identityHash="-4560494593"]
Actual:   [[Original date: 2009-03-07T19:30:00.00-05:00], 
identityHash="-4551321553"]

There are two differences compared to the past (I only ran the samples tests 
some months ago):

0500 changed to 05:00
08T00:30 changed to 07T19:30

The line in timezone.rex where it fails is:

  say 'Original date:' finalTime~utcIsoDate

finalTime is an instance of the DateTime class

When I looked at the latest rexxreff.pdf it states for the method utcIsoDate:

Returns the timestamp formatted as a string in ISO timezone-qualified date 
format. If the timezone offiset is 0, the format is 
-mm-ddThh:mm:ss.uuZ. If the offset is positive, the string is formatted 
as -mm-ddThh:mm:ss.uu+hhmm. If the offset is negative, the result will 
be in the format -mm-ddThh:mm:ss.uu-hhmm.

The current output is thus not consistent with the documentation.

Shall I report this as a bug or can you take it from here? The first change is 
merely formal but the 2nd one I am not sure how to interpret.

The testcases for all the samples were offered in March this year and can be 
found here:

https://www.dropbox.com/sh/p66c7g01h4jz5ss/AAAZd_Q2yQddrTHagxPo_UiTa?dl=0 


PS good news is that all other samples test cases worked fine :-)

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se




___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel