Suspected Bug: Timestamp rounding

[intra]

Hi,

I seem to be having an issue with time stamping in Version 6 (Build 2010), I've included a quick BSV and would like to see if anyone else has the same issue?

Description:

I have two processes

Process: Create
Logic: CREATE WORKLOG WITH START_TIME=CURRENT_TIMESTAMP

Process: STOP
Logic: FIND WORKLOG WHERE WORKLOG.END_TIME IS UNDEFINED TAKE BEST 1
WORKLOG.ENDTIME = CURRENT_TIMESTAMP
WORKLOG.DURATION_SECONDS = (WORKLOG.END_TIME - WORKLOG.START_TIME)/60000

Issue:

When i run the "Create" process AwareIM correctly adds a line to the MySQL table with the correct start_time

When i run the "Stop" process AwareIM seems to round the "End_Timestamp" which throws out the calculation for WORKLOG.DURATION

Can someone confirm this on their system too?

Regards

Peter.

[aware_support]

Are you able to prepare a small BSV that demonstrates the problem and describe how to reproduce it in this BSV?

[intra]

There's a zip file with the bsv attached already.

[intra]

Did anyone else have the same issue?

[aware_support]

Please describe how we can reproduce the problem in the attached BSV - step by step.

[intra]

1. Put the BSV into test mode
2. Open up a database workbench tool (in my case MySQL Workbench)
3. In the workbench open up the table BASTESTDB(BS)WORKLOG
4. Go back to AwareIM and login to test mode with admin account
5. Press the "Start Clock" button which is in the administrator VP along the top of the screen
6. Open up the workbench and look for the recent row entry it should be something like this below.

ID: 12345 (Actually the next number in sequence from BAS_IDGEN.MAX_ID)
BASVERSION: 1
BASTIMESTAMP: 2015-01-22 11:39:41 (Actually the current timestamp on the system at the time)
START_TIME: 2015-01-22 11:39:41 (Actually the current timestamp on the system at the time)
END_TIME: NULL
DURATION_SECONDS: NULL

7. Go back to AwareIM Test Mode and now press "Stop Clock"
8. Go back to the workbench and look at the updated row. It will look something like this.

ID: 12345 (Actually the next number in sequence from BAS_IDGEN.MAX_ID)
BASVERSION: 2
BASTIMESTAMP: 2015-01-22 11:40:06 (Actually the current timestamp on the system at the time)
START_TIME: 2015-01-22 11:39:41 (Actually the current timestamp on the system at the time)
END_TIME: 2015-01-22 11:40:00
DURATION_SECONDS: 0.316667

The correct answer should be

ID: 12345 (Actually the next number in sequence from BAS_IDGEN.MAX_ID)
BASVERSION: 2
BASTIMESTAMP: 2015-01-22 11:40:06 (Actually the current timestamp on the system at the time)
START_TIME: 2015-01-22 11:39:41 (Actually the current timestamp on the system at the time)
END_TIME: 2015-01-22 11:40:06
DURATION_SECONDS: 0.416667

*note* i know the DURATION_SECONDS column name is misleading, the reason why it named it this was purely due to me trying to figure out the difference in seconds, however for me it was easier just working with minutes. I just didn't update the attribute name.

[aware_support]

Seconds are cut-off from the value when a timestamp is assigned by rules, unless the format of the timestamp includes seconds. So you need to change the format of the timestamp to have seconds, for example dd/MM/yyyy HH:mm:ss

[intra]

Support,

Ok that works, changing the timestamp rule from DD/MM/YYYY HH:mm to DD/MM/YYYY HH:mm:ss on both the Start_Time and End_time attributes fixes this issue.

Doesn't explain why the initial Start_Time timestamp went to the seconds precision in the first place when it was clearly DD/MM/YYYY HH:MM.. anyways.. happy with this solution. THANKS!