Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (6)

Resolved Date() no longer works as expected

  1. Issue
0
Votes
Undo
  1. Larry Peters
    Larry Peters
  2. PowerBuilder
  3. Tuesday, 2 February 2021 20:52 PM UTC

I have the following code:

string            ls_date = "1900-01-50"
date            ld_date
ld_date = date(ls_date)
messagebox("Date", string(ld_date, "dd-mm-yyyy"))

When run using PowerBuilder 12.5.2 (my legacy system) the result in the messagebox is "01-01'1900".

When run using Appeon 17R3 (my current system) the same code results in "05-01-1900".

The problem is the legacy system is expecting "01-01-1900" as being an "empty" date but the same code, when complied and run in 17R3 no longer works as expected. It looks like the 17R3 implementation of Date() has changed.

Has anyone else experienced this and can anyone throw light on this difference and is it a known issue likely to be fixed?

Larry Peters

  1. 64-bit
  2. DATE
  3. PB Classic
Powerbuilder 2017 R3 - Gitlab Enterprise - Automat...
PB2019 R3 - Click on edit attribute tries to do re...
Accepted Answer
mike S
mike S Accepted Answer Pending Moderation
  1. Wednesday, 3 February 2021 16:07 PM UTC
  2. PowerBuilder
  3. # Permalink

as per PB help: "Returns the date in string as a date. If string contains an invalid date or an incompatible datatype, Date returns 1900-01-01. If string is null, Date returns null."

 So, this is a clearly a BUG and you need to enter it into the bug reporting system:    https://www.appeon.com/standardsupport/search

 

doesn't really matter who broke this, appeon will fix it once they know about it

 

your original programmer wrote things "correctly" and by that i mean it should continue to work the same way in each version.  However, if you are maintaining this code long term, you should probably switch ISDATE since using 1900-01-01 is a bit weird.  I always hated the dreaded 1900-01-01 and never understood why null wasn't used instead.

 

In any case i agree with armeen that you should move directly with 19R3.  That version will probably get fixes first.

 

 

 

 

Comment
Larry Peters
  1. Larry Peters
  2. Wednesday, 3 February 2021 21:31 PM UTC
Hi Mike,

Thanks for the feedback. I believe you are right, the Help does clearly say:

Date. Returns the date in string as a date. If string does not contain a valid date, Date returns null.



So returning 05-01-1900 is a valid but wrong date.

I will log this and keep you all informed.

I will of course move to 19R3 asap but not this week.

Regards

Larry



  1. Helpful
There are no comments made yet.
Responses (6)
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 2 February 2021 21:32 PM UTC
  2. PowerBuilder
  3. # 1

Hi Larry;

   Since "1990-01-50" is an invalid date ... why not just set the initial value to "1990-01-01" in the first place?

Regards ... Chris

Comment
Larry Peters
  1. Larry Peters
  2. Wednesday, 3 February 2021 01:09 AM UTC
Hi Chris,

I think I know why the code is the way it is.

In PB12.5.2 date("1900-01-50") returns 1900-01-01. So does date("2021-02-31").

So the programmer was testing some random date string. For example "2021-02-31". So what he did was test that date: ls_date = "2021-02-31" and if date(ls_date) = date("1900-01-50") then this is a bad date string. Works fine in PB12.5.2 because both sides return the same 1900-01-01 value.

However in 17R3 it won't work because date("2021-02-31") returns 1900-01-01 and date("1900-01-50") returns 1900-01-05.

Much easier to use IsDate(ls_date).

Regards

Larry
  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Wednesday, 3 February 2021 01:31 AM UTC
Interesting approach assuming a bad date would precipitate another bad date. Yes, IsDate() would have been the correct coding mechanism from the onset. ;-)
  1. Helpful
There are no comments made yet.
Miguel Leeuwe
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Tuesday, 2 February 2021 22:32 PM UTC
  2. PowerBuilder
  3. # 2

Interesting:

date ld_null
string ls_null_date

setnull(ld_null)
ls_null_date = string(ld_null, 'dd-mm-yyyy')

Results using PB 12.6:
ls_null_date = '01-01-1900',
IsDate(ls_null_date) returns TRUE, and
Isnull(ls_null_date) returns FALSE

Results using PB 2019 R3 (and probably 2017):
ls_null_date = "",
IsDate(ls_null_date) returns FALSE and
Isnull(ls_null_date) returns TRUE

If you have a lot of code in a lot of applications, that might be quite a job to correct.

A part from that, I don't think then when assigning "1900-01-50" you should get a valid date or "null" date... Not in pb 12.5.2, neither in pb 2017 / 2019.
In my humble opinion the ld_date = date(ls_date) should throw and exception.

regards.

Comment
There are no comments made yet.
Larry Peters
Larry Peters Accepted Answer Pending Moderation
  1. Wednesday, 3 February 2021 00:18 AM UTC
  2. PowerBuilder
  3. # 3

Hi Chris,

I have no problem knowing how to correct the code. I don't like the code anyway.

However, the issue is it worked fine in PB12.5.2 but not in 17R3. In other words, 17R3 is NOT backward compatible with PB12.5.2 and that means code checking a very large application and then a mountain of regression testing.And now the uncertainty of wondering if any other functions have similarly changed. I think breaking backward-compatibility is a major no-no.

THAT is my problem.

Regards

Larry

Comment
Armeen Mazda @Appeon
  1. Armeen Mazda @Appeon
  2. Wednesday, 3 February 2021 00:43 AM UTC
Hi Larry,

Pretty much every single version of PB has made changes... take a look at this huge migration guide by PB version: https://docs.appeon.com/pb2019r3/upgrading_pb_apps/index.html

Secondly, I don't know of a single software that is free of any regression bugs. So it goes without saying that anytime you upgrade to a new major version you need to do comprehensive testing anyway.

With that said, I would recommend you upgrade to PB 2019 R3 instead of PB 2017 R3, because it is the newest long-term support version and has a ton of new features compared to PB 12.x so get the biggest bang for your upgrade effort: https://www.appeon.com/developers/powerbuilder-release-history.html

Best regards,

Armeen
  1. Helpful
Larry Peters
  1. Larry Peters
  2. Wednesday, 3 February 2021 01:18 AM UTC
H Armeen.



We went through comprehensive testing when we upgraded to 17R3. However we did NOT test every function.

In other words we did NOT do "Retest All". Instead we did "Test selection" and "Test cases prioritized".



Obviously we expect regression bugs - either new ones or old ones rolled back but NOT that the return values from primitive functions would change.



Anyway, I'm now somewhat daunted by needing to do all the testing again for 19R3. What Easter eggs will we find?



Thanks anyway



Larry
  1. Helpful
Armeen Mazda @Appeon
  1. Armeen Mazda @Appeon
  2. Wednesday, 3 February 2021 03:05 AM UTC
I really don't think there is going to be much more easter eggs in 2019 R3 than what you have already found in 2017 R3. If you do, I will give you my personal phone number and you can yell at me. :-)
  1. Helpful
There are no comments made yet.
Ken Guo @Appeon
Ken Guo @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 3 February 2021 10:41 AM UTC
  2. PowerBuilder
  3. # 4

Hi Larry，

I used multiple PB versions to test locally and the test results are below:

  • Both PB 9 & PB 10 return ’1900-01-01’.
  • PB 11.5, PB 12.5, PB 12.6, PB 2017, and PB 2019 all return ‘1900-01-05’.

 My environment is Windows 10 64-bit English. The region setting is English(US). Can you tell me your Windows environment?

Does the issue exist if you use other machines to test?

 

Regards,

Ken

Comment
Larry Peters
  1. Larry Peters
  2. Wednesday, 3 February 2021 21:43 PM UTC
Hi Ken,



My code is:

string ls_date = "1900-01-50"

date ld_date

ld_date = date(ls_date) // this converts to date REGARDLESS of regional settings because yyyy-mm-dd is internal date format

messagebox("Date", string(ld_date, "dd-mm-yyyy"))



My understanding is that when using DATE(yyyy-mm-dd), the region setting is irrelevant.

The region setting only becomes relevant when trying to display a date without formatting.

In other words, if I have a valid date, I can display it as

dd-mmm-yyyy using STRING(ld_date, "dd-mmm-yyyy") or as

mm-dd-yy using STRING(ld_date, "mm-dd-yy")

REGARDLESS of my region settiings.



fwiw my setting is

Country:Australia

Format: English (Australia)

Short Date d/MM/yyyy

Long Date dddd, d MMMM yyyy

Windows 10 Version 1909 (OS Build 18363.1350)



Regards

Larry
  1. Helpful
There are no comments made yet.
Benjamin Gaesslein
Benjamin Gaesslein Accepted Answer Pending Moderation
  1. Wednesday, 3 February 2021 15:02 PM UTC
  2. PowerBuilder
  3. # 5

Some results in 2019R2: (results are dd.mm.yyyy, which is the date format set in the Windows regional settings)

Date("1900/01/50") = 05.01.1900

Date("1900/01/502131209412934012390123") = 05.01.1900

Date("1900-JAN-50") = 01.01.1900

Date("1900-02-31") = 01.01.1900

Date("1900-FEB-28111111111") = 01.01.1900

Date("1900-02-28111111111") = 28.02.1900

Apparently both date('yyyy-mm-dd') and date('yyyy/mm/dd') always truncate the "day" value to the first two digits. If the remaining number is larger than the number of days in the given month but smaller or equal 31, 01.01.1900 is returned. If it is larger than 31, anything past the first digit is ignored and the first digit is used for the day.

No such shenanigans are happening with formats like YYYY-MMM-DD.

Comment
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.