Activity Time Stamp way off yet Time Synched correctly

[Bob]

Just more clarification so people don't panic too much.

This bug is because a reporting module is using the OLD DST dates.  DST was changed to start later and end earlier as it did this month.   OLD DST date is April 6th.  Once April 6th comes around it will put the hour back on the reports.   The problem will return in fall and spring until a programming update is made to correct DST dates.

What's confusing is the problem is sporadic meaning not all agencies experience it.  If you do find your in this situation, contact Applied Support and add name to list.   Again know it will correct itself when April 6th arrives.

[Jeff Zylstra]

Very interesting.  I would think that Windows would control the DST and time change elements, and not TAM's coding.  Is this machine up to date on all of your Windows updates?  Just wondering if someone else with proper TAM security logged in on their computer using their Windows account if they would get the same error?   

[Bob]

LOL don't think so Jeff.  Experienced by all 5 offices.  It's TAM specific and Applied acknowledged.  Nothing for me to do but deal with it until April 6th and hope before fall they have an update to correct it.

It a programming mistake in the reporting module not updating the new dates for DST so reports are subtracting an hour from the real recorded data.   

I recommend everyone check the time stamp on your activity reports.  One of the rare places that uses TIME stamp in report.  Flaw is not in TAM itself but again the activity report (it uses time stamp) calculating it wrong.  Data in TAM is correct just the time interpreted wrong by report do to DST oversight.   

[Jeff Zylstra]

Very interesting.  I would have thought that something like this would be handled entirely by Windows and not TAM.  I guess that's why Y2K was such a pain in TAM too.  Oh well. Some day they'll have to scrap all of this old technology.

[Bob]

scrap all of this old technology.

+1   I'm waiting for TAM to retire.   I ordered a new server Epic ready (or maybe something else).   1.5TB RAID 96Gigs of RAM, much more..  When I get back from Phoenix, were migrating from SBS2003 Server 2012, put Outlook in cloud keep other Office apps in house so I don't find ourselves being down one day with an update that TAM doesn't support.   

[Alice Mooney]

scrap all of this old technology.

+1   I'm waiting for TAM to retire.   I ordered a new server Epic ready (or maybe something else).   1.5TB RAID 96Gigs of RAM, much more..  When I get back from Phoenix, were migrating from SBS2003 Server 2012, put Outlook in cloud keep other Office apps in house so I don't find ourselves being down one day with an update that TAM doesn't support.

Noooooooo!!!!

[Mark]

+1 Conan, you Da Man!

[Toni Forte]

Just more clarification so people don't panic too much.

This bug is because a reporting module is using the OLD DST dates.  DST was changed to start later and end earlier as it did this month.   OLD DST date is April 6th.  Once April 6th comes around it will put the hour back on the reports.   The problem will return in fall and spring until a programming update is made to correct DST dates.

What's confusing is the problem is sporadic meaning not all agencies experience it.  If you do find your in this situation, contact Applied Support and add name to list.   Again know it will correct itself when April 6th arrives.

Bob, Thanks for the heads up, we are on TAM 12.2 and just verified this is happening to us as well.  Will contact Applied and see if we can be added to the PMR so they know there are more agencies with this issue.

[Bob]

Maybe we stumbled on something bigger than we thought?  Glad you checked it out.