While at it ...

Here's a small sample app. (pb2017)

To see if it works you have to debug the itemchanged event.

if you have a common dw ancestor like 'u_dw' when using pfcs:

Put this code in the ItemChanged() event. It's not perfect and might need also some checks using the max value of your windows range (which I haven't coded).

If you'd type in as a date:

24.04.37

PB would interpret that (wrongly) as 24.04.2037

Then the code lowers the date with a 100 years and keep that value if it's within the ranges of your Windows settings.

What would happen if you'd have a leap year and someone was born on 29th of February 1932?
Seems like it's not a problem (not completely sure if there are any exceptions): 2032 and 1932 are both leapyears, so the initially obtained date of 29.02.2032 is a valid date for PB for us to work our code on:

if dwo.format = "[shortdate]" then
	date ld_date
	
	ld_date = Date(DATA)
	if year(ld_date) > 1999 then
		// then you got a date in 21 century, have to check:
		// your min value = 1931 and max value = 2030
		// diminish the date with a hundred years:
		ld_date = Date(year(ld_date) - 100, month(ld_date), day(ld_date))
		// 1931 should be in some instance variable, not hard coded like I do here:
		if year(ld_date) >= 1931 then
			// this new date is the one you really wanted:
			this.SetItem(row, string(dwo.name), ld_date)
			return 2 // to reject the initial input in DATA and accept the value set with SetItem
		end if
		
		// you might also have to do some checking with the MAX value of your windows range 
		// .... to be coded ... 
		
	end if
	
end if
return 0

I think my initial check on format being "[shortdate]" would work for all date fields, as long as they have that format set. (but you could use some value in columns' tags to indicate the check should be done and check on that).

Hope it gives you the initial steps for your solution.

regards

Thanks for your help,

but as I already wrote, it's not about the format, but about the interpretation of a two-digit year.

Benjamin

EDIT: I've read you question a bit better now (sorry).

So this answer is probably no good:

----------------------------------------------

Here's the attached zipped GIF video.

Using pb2019 r2.

You have to set the format to be [shortdate] there's 2 places you have to do that.

Then you have to know how to change the format in W10, which is not as easy as it was on older windows versions anymore.

Another solution could be:

- read the format for date format setting from the registry:

HKEY_CURRENT_USER\Control Panel\International\sShortDate

- in the constructor event of your datawindow,run through all columns and apply that format on the date fields.

HTH.

Sorry, but the format is not the point.

We distribute our software in Germany, Austria and Switzerland. There is no military standard and the standard format is "dd.mm.yyyy".

In the year 2020 it should be possible for RAD software for Windows programs like PowerBuilder to respect the corresponding settings of Windows.

Benjamin

Another opinion:

The format proposed by Chris is, in effect, military time:  2020-08-18.
It's very clear, and more importantly it can be sorted in that format.

I store my dates in this manner, and display them as 18-AUG-2020.

 ~~~~~~~~~~~~~~~~~~~~~~

To answer your question, ensure that you are saving the dates in a DATE format for your database.
Then in the code you cxan use the algorithm you already stated to determine the CC portion of the CCYYMMDD date, and store the full CCYYMMDD date in the database.

Olan

Hi Benjamin;

   FWIW: I always have built my PB Apps using the ANSI date standard CCYY-MM-DD and found that App users preferred this format as it's very clear. Also, all major DBMS software uses this standard internally as well (so does PB).

Just my $0.02

Regards ... Chris