Dates 2030+

JohnGage · July 30, 2010, 11:36:31 AM

What are you doing for dates in TAM post 12/31/2029? At least in the eff and exp date fields anything 2030 or great is converted to 1930. We are running into problems with LIFE policies.

I had hoped changing the Windows Date setting would fix this but alas the problem appears to be in the TAM code.

Bloody Jack Kidd · July 30, 2010, 11:43:07 AM

dunno about that - it's the 2038 unix date issue that concerns me.

Lance Bateman · July 30, 2010, 01:06:27 PM

Problem with the "2000 fix" that wasn't really a fix. (That's why when I was overseeing a new project in 1990 I rejected any coding that didn't have full 8 digit date fields). We just coded "continuous until cancelled" policies for that date, knowing that at some point in the future we'd have to update them, if the database hadn't been fixed.

Quote from: JohnGage on July 30, 2010, 11:36:31 AM
What are you doing for dates in TAM post 12/31/2029? At least in the eff and exp date fields anything 2030 or great is converted to 1930. We are running into problems with LIFE policies.

I had hoped changing the Windows Date setting would fix this but alas the problem appears to be in the TAM code.

mblack · July 30, 2010, 02:12:18 PM

Retiring

DebAmstutz · July 30, 2010, 02:43:24 PM

What I've done is use 2029 and then put a note on the note portion of the billing screen such as "actual expiration date is 2048" or whatever year the policy actually expires.

Joshua Conner · August 02, 2010, 02:27:15 PM

Wrote about this on my blog back in January. http://mylifewithtam.blogspot.com

We are just leaving it at 2029 with a sticky note attached.

woo hoo my first post over here!

Gene Foraker · August 02, 2010, 02:56:05 PM

Welcome, Joshua!

I haven't had much yet, but I would suggest also adding an open activity CHXD Change X Date, for 12/31/29. That way it is searchable for when Applied fixes it and if any don't get changed by then, they will pop up.

Jim Jensen · August 02, 2010, 03:27:49 PM

I assume by now you realize it has nothing to do with Windows. I can't believe a tech would have told you that. Those of us around since 1999 know better. Hints of it appeared in 10.0 when dates on some forms started printing B0. Their little "Y2K+10" problem.

JohnGage · August 04, 2010, 09:29:27 AM

A tech didn't suggest that the Windows setting would fix the problem I was just hoping it would. Had I taken :10 seconds to think about how TAM stores dates as basicly text I wouldn't have even bothered.

Good idea about entering the CHXD activity!

Hans Manhave · August 04, 2010, 09:43:39 AM

As relatively simple as it is to convert the A and B into 0 and 1, one would think that a .x update of TAM could have expanded it to through G or H and nobody would ever have to look at it again. I'm assuming Epic was never programmed with this Y2K fix.

Jim Jensen · August 04, 2010, 10:58:28 AM

Quote from: JohnGage on August 04, 2010, 09:29:27 AM
A tech didn't suggest that the Windows setting would fix the problem I was just hoping it would. Had I taken :10 seconds to think about how TAM stores dates as basicly text I wouldn't have even bothered.

Good idea about entering the CHXD activity!

My apologies, I misread your posting. I"m with Hans too - I can't believe they can't at least add some code to insert C, D, E, F and buy another 40 years. I don't expect TAM to live anywhere near that long, but we do have to display dates that far in advance. For that matter, They need to make sort of effort on some other fields that still truly only have 2 digits and can't be assumed whether it's 19xx or 20xx. I'm thinking particularly of system updates on property apps. I can easily have a heating system in a building from 1910, but if I put in "10" it will be assumed to be 2010. Our church's boiler was installed in 1927. We replaced it only because of efficiency - it still functioned perfectly well.

Dates 2030+

Lance Bateman