Activity Time Stamp way off yet Time Synched correctly

Bob · March 25, 2014, 01:49:19 PM

I logged a request for support but thought I would post and run by you all for ideas while I await a return call.

Monitoring an employee who came in late. I wanted to view activity report for this morning. She didn't arrive until almost 9am but he 1st activity was at 7:30am with a few others in that same hour and so on. I then ran for everyone noticed same problem, time is being stamped almost 1.5 hours earlier than actual time.

My server is synched to an Atomic Clock and pushed out to the workstations company wide. I verified server and all workstation have exact proper time. I'm puzzled why TAM would use incorrect time. It's not even a time zone as it's not off by even hour or two more like 90 min.

Just curious for ideas as I wait for call and if anyone else has had this problem with TAM 2013.

Mark · March 25, 2014, 02:02:32 PM

Just curious -- is the clock on Homebase correct?

Bob · March 25, 2014, 02:10:51 PM

Yes it is.

Todd Arnold · March 25, 2014, 02:18:30 PM

TAM stores activity date+time in GMT. It then converts that stored GMT to your local time zone when you look at it. So, is the computer you are using to look at this activity set to the correct time zone? Could your computer have the right time, but think it's in the central time zone?

Bob · March 25, 2014, 02:23:32 PM

I'm puzzled but I will go check again. Server keeps them in synch and since everyone and mine is set for PST and time correct (verified as I wrote on mine), still puzzles me. Must puzzle Applied too as no call yet.

Something that just started.. We audit by time often not seen this in past.

Jeff Zylstra · March 25, 2014, 03:34:34 PM

However this resolves, Applied relies heavily on the time stamp for the authenticity of an activity. I think that their Time Tampering utility is their method of determining if someone tries to change a workstation and/or server time or date and tries to "fool" the system. If server and workstation times don't match up, the authenticity of your activity file and documentation will be called into question if you ever have to go to court for an E&O or other reason.

I'm interested in seeing how this comes out. Please post the "solution" when you get it.

Bob · March 25, 2014, 03:58:01 PM

Forgot about that tool can't hurt to run. My luck everyone will need to be out.

When I get my call and answer, I'll share so far no call yet..

Bob · March 25, 2014, 04:53:36 PM

Nothing with time stamp utility.. I did some testing (by the way still waiting on Applied to call, seems like support from long ago).

The actual data and activity has correct time. Activity report is reporting them incorrectly. Reports have been reindexed over and over as well. While everything being done is correct passing the data off to report, it changes the time on the report from the actual time on record.

Jeff Zylstra · March 25, 2014, 05:12:51 PM

Quote from: Bob Connor on March 25, 2014, 04:53:36 PM
Nothing with time stamp utility.. I did some testing (by the way still waiting on Applied to call, seems like support from long ago).

The actual data and activity has correct time. Activity report is reporting them incorrectly. Reports have been reindexed over and over as well. While everything being done is correct passing the data off to report, it changes the time on the report from the actual time on record.

Sounds like an undocumented program enhancement to me.

That's probably why you aren't getting a call back from the "front line, rapid response" support crew. My guess is that this will take longer than the customary 15 minutes that they're allowed.

Bob · March 25, 2014, 07:05:53 PM

Ok spent an hour or more with support tamdbfr utility and found nothing but report is subtracting an hour from real time. Applied is puzzled as I am as everything is correct so I have experiment some so tonight run Synch Tfile notes. Hoping that fixes the report.

It does appear out of the blue TAM reports forgot daylight savings yet TAM itself did not. When I find answer I will post back and share.

Conan_Ward · March 26, 2014, 11:42:23 AM

It's DST related, there is a PMR and I've let the tech you're working with the # so he can work on getting another entered for your office.

Sorry for the delay, been a busy few days and haven't had time to dig

Bob · March 26, 2014, 11:44:45 AM

Awesome Conan! Thanks! I just wrote him too said some module in TAM is missing DST why reports are wrong but data in tam correct.

Much Appreciated! +1

Conan_Ward · March 26, 2014, 11:47:54 AM

To be honest, I've kinda looked at the thread a few times but hadn't had the time to dig, and then you mentioned DST and figured that had to be it, so the search took 2 seconds.

Jeff Zylstra · March 26, 2014, 12:00:35 PM

props and +1 to Conan for an excellent catch!

Bob · March 26, 2014, 12:25:19 PM

Just got an email from the tech advising it is a DST glitch and only affects reports not the real data. Programmers are working on it and I am added to a list of other Agencies with this unusual bug. So answer is deal with it until a fix can be developed.

I would caution anyone on TAM 2013 to periodically check the system time stamp on activity report. This happened on its own and was working fine until this last week. Just because things look ok now, doesn't mean the time stamp can't go bad on you in reporting as ours did. We have been on 2013 since last TENCon and this is new to us. Users beware!

Conan maybe slip them a tip while they work on that time stamp issue. If they are going to work on the Time Stamp then do it right. Let the activity report put things in TIME order so we have picture of ones day. Currently no way to sort by time so one activity on report might by 2pm another 9am just bounces all over. Shame because I prefer I time ordered activity report to reflect what our staff is doing with time. Great opportunity to get it right since they have to work on it anyhow. I'll give you +30 you swing that. Ha!

Bob · March 26, 2014, 12:58:56 PM

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 · March 26, 2014, 02:02:14 PM

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 · March 26, 2014, 02:14:11 PM

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 · March 27, 2014, 02:40:25 PM

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 · March 27, 2014, 03:25:52 PM

Quote from: Jeff Zylstra on March 27, 2014, 02:40:25 PM
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 · March 27, 2014, 04:04:56 PM

Quote from: Bob Connor on March 27, 2014, 03:25:52 PM
Quote from: Jeff Zylstra on March 27, 2014, 02:40:25 PM
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 · March 27, 2014, 04:59:50 PM

+1 Conan, you Da Man!

Toni Forte · March 28, 2014, 02:27:07 PM

Quote from: Bob Connor on March 26, 2014, 12:58:56 PM
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 · March 28, 2014, 02:46:06 PM

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