Forums

by Andrew Hall >> Tue, 11 Jan 2000 20:45:55 GMT

Yesterday I raised the following issue with Jade Support via the web about '99' being converted into '2099'. I accept that Jade is behaving exactly as documented in FAQ 13213 but feel it would be better if it did the following: if 2 digit date form of current year is < 50 then
if 2 digit date entered is > 50 then
century equals current century-1
otherwise
century equals current century
otherwise
if 2 digit date entered is > 50 then
century equals current century
otherwise
century equals current century+1

Does anyone agree? Or not? I've included Jade Support's response below which I must confess I don't fully understand. Their suggestion that I could have my own code to do the above logic is of course perfectly true, however the base Jade logic occurs whenever you do a '.Date' type-cast and since you can't overload a type-cast with your own logic (can you?), all '.Date' type-casts would need to be replaced with my specialist '.doDateProperly' method. Comments?

1. 11Jan00 12:40 TURING
FAQ 13213 explains the Jade's policy regarding 2 digit years. I believe this should be modified ASAP so that for 2 digit dates entered later than 1999 (ie. now in 2000) if < 50 keep the current century (ie. 20) but if > 50 then use the previous century (ie. 19). This 2nd stage of logic would reflect that already in place for pre-2000 entered dates.
2. 11Jan00 14:01 SGP
I have discussed this with the plant and the default JADE behaviour for defaulting a 2 digit year's century is not going to change.
If you have application specific requirements that differ you will need to either force the user to enter 4 digits for the year or alternately put some of your own code in to parse the appropriate fields and adjust them as appropriate prior to converting the textbox text to a date. Of course, if you put in a rule that dates > xx are 19xx your application will need adjusting again in the future when this 100 year window is no longer appropriate.
JADE's rule for defaulting the century was made such that it never needs adjusting in this way and so there is no guess-work required to determine if a given year will default to the 20th or the 21st century (or the 21st or 22nd century etc).
Contact Closed

by Darrell Duniam >> Tue, 11 Jan 2000 21:17:49 GMT

I agree with the Support people ... it makes sense to default to the current century if the century is not supplied. Why don't you just bung a method on the Date primitive to adjust the century according to your needs ?

darrell.
-----------------------------------------------------------

by Andrew Hall >> Wed, 12 Jan 2000 1:11:30 GMT

I agree with the Support people ... it makes sense to default to the current century if the century is not supplied.

But we weren't doing that up until 2 weeks ago. Jade is saying it was okay to be clever about 2 digit dates up until Dec 31st 99 for the entry of future dates but now that it's past that date they don't want to apply the same logic to helping the entry of 2 digit dates for past dates.

Why don't you just bung a method on
the Date primitive to adjust the century according to your needs ?

Yes I guess that's the only way to do it but it still means I have to replace all the '.Date' type-casting with the new specialist method.

Andrew

by John Porter >> Tue, 11 Jan 2000 21:44:36 GMT

There is a simpler algorithm, as used by many software packages:

if 2 digit year entered is > 50 then
century equals 19
otherwise
century equals 20

I believe some versions of Excel use 30 as the cut-off year, LINC defaults to 57.

Of course you could always store 4-digit years... the end users can still see 2-digit ones.

Cheers,
John P

by Martin Sperring >> Tue, 11 Jan 2000 21:47:37 GMT

Yesterday I raised the following issue with Jade Support via the web about '99' being converted into '2099'. I accept that Jade is behaving exactly as documented in FAQ 13213 but feel it would be better if it did the following: if 2 digit date form of current year is < 50 then
if 2 digit date entered is > 50 then
century equals current century-1
otherwise
century equals current century
otherwise
if 2 digit date entered is > 50 then
century equals current century
otherwise
century equals current century+1

I can see you're looking to create more work for the IT industry around the mid-century....
eg. In 2049 if you enter '51' as a year you'll end up with 1951 when more than likely the user is meaning 2051.

A better approach might be:

if current date is < 50 and
date entered is > 50 and
(date entered - current date) > 50 then
century = century - 1

by Andrew Hall >> Wed, 12 Jan 2000 0:34:32 GMT

Good point Martin.
But do you agree that such code would be handy at the base Jade level? or do you agree with Darrell that we shouldn't be trying to do anything clever with dates that have been entered as 2 digits and should always just use the current century?

Andrew

by Stuart Greaves >> Thu, 20 Jan 2000 0:42:11 GMT

Andrew,

I agree with your original point, and have had no less than 3 ISVs complain to me about the manner in which JADE treats such 2-digit year dates. I was very surprised to see that "31/12/99" means "31/12/2099" to JADE. I also wasn't entirely happy with the 'official' response given, and find it hard to accept the 'Jade's behaviour hasn't changed' argument. Well, for these ISVs, a couple of weeks ago it certainly did change overnight.

A 'floating' plus/minus 50 year from current year, for interpretation of 2-digit YY dates, is my preferred approach, FWIW.

Stuart

by John Porter >> Wed, 12 Jan 2000 4:24:04 GMT

I can see you're looking to create more work for the IT industry around the mid-century....
eg. In 2049 if you enter '51' as a year you'll end up with 1951 when more than likely the user is meaning 2051.

Similar to the current Jade implementation. To quote from the faq:

"JADE uses the following rule for defaulting a 2 digit year:

If the current year is <= 50 then all dates default to the current century.
If the current year is > 50 then dates >50 default to the current century.
If the current year is > 50 then dates <=50 default to the next century."

So on 4 January 2051 if you want to finish up last week's data and enter 28dec50 it will be taken as 2150.

Cheers,
John P

by Iain S. Kerr >> Wed, 26 Jan 2000 23:24:38 GMT

I agree with Stuart Greaves that the best approach is to use a floating 50 year window for date determination. This will ensure that the system will respond in a user friendly manner no matter when the date is keyed in to the computer.

For example
1. If current year is 2025 then going forwards all two digit years from 25 to 75 will be assumed to be century 2000. Going backwards 76 to 99 will be 1900 and 00 to 25 will be 2000.

2. If current year is 2070 then going forwards all two digit years from 70 to 99 will be 2000 and 00 to 20 will be 2100. Going backwards 21 to 69 will be 2000.

iain.kerr@ibconsultants.com.au