FormCalc age won't calculate dob for anyone born before 1930

[MissyC2015]

creating a form and would prefer age to auto calculate using first attempt age always read 120; change to if/then the age shows blank until data entered; however anyone born prior to 1930 it does not calculate, doesn't even recognize 19xx dob and changes the year to 20xx

if(HasValue(DOB))then

if(HasValue(Date))then

var Date_=Date2Num(Date.formattedValue, "MMMM D, YYYY")

var DOB_=(DOB.formattedValue, "MMMM D, YYYY")

var diff = Date_ - DOB_

$.rawValue = Floor((diff/7)/(52))

else

$.rawValue = null

endif

else

$rawValue = null

endif

Any help would be great. Wondering if it's a format issue. 

[Test Screen Name]

Is this question relating to XFA forms made with LiveCycle Designer/AEM Designer?

[Bernd Alheit]

Why does you use the function Date2Num only for the calculation of Date_ ?

[MissyC2015]

Yes refers to XFA forms made with LiveCylce Designer ES4; was one of many that calculations found upon googling to get my solution to auto calculate age

[MissyC2015]

So more research is telling me LiveCycle Designer won't recognize dates prior to 1930 as anything 19xx due to Epoch date ... is there maybe a way to 'make' it reocognize a year prior to this using Javascript?

[Bernd Alheit]

Try following forum:

https://experienceleaguecommunities.adobe.com/t5/Adobe-LiveCycle/ct-p/adobe-livecycle-community

[try67]

That's strange because the epoch of the JS Date object is 01-01-1970, and it can certainly display earlier dates than that (by using negative values for the time before the epoch). Did LCD invent its own Date object? If so, that might explain this issue...

[Test Screen Name]

I read some part of the FormCalc document for XFA files. For 2 digit year, certainly 1930 is the oldest available. "30" means "1930" but "29" means "2029". This seems a disaster waiting to happen in the next few years. Does not seem to apply to your case UNLESS somewhere there is a 2 digit year format.

[try67]

The util.scand method has the same issue, but between 49 and 50... Yet another reason to always use 4 digits for the year, if the Y2K-bug was not enough.

[Test Screen Name]

I worry more about the year 2038 problem as it will affect every 32-bit system and every 32-bit app. Especially with ludicrous things like the Surface Pro X forcing users BACK to 32-bit apps after years of promoting 64-bit.

[try67]

Really? How short-sighed... I was expecting this issue to be solved by moving to 64-bit applications, but it seems that might not be the case after all. There's so much legacy software out there that it would probably require a Y2K-type operation to solve it.