Inconsistent Time Offset in Date Variables

Brian Mellert · May 1, 2012

I am assigning, and comparing, date/time values in 9.1.2. I've noticed that ProcessContext.CurrentTime contains a time zone offset, but any time a value is assigned to a date/time variable the time zone offset is "zeroed out". (We're in the eastern US time zone.)

ProcessContext.CurrentTime=5/1/2012 12:10:12 PM -04:00

Assign Incident_Occurred=ProcessContext.CurrentTime, resulting in

Incident_Occurred=12/8/2011 1:24:00 PM +00:00

The time portion is correct and matches, but the time offset throws things off. Even doing

CalculateDuration(ProcessContext.CurrentTime,NOC_AlertsData.Incident_Occurred,DateTimeUnits.Hours) results in -4 (hours) even though they "are" (or should be) the same time. It also causes issues if using Earliest / Latest in comparison to ProcessContext.CurrentTime.

Why aren't offsets being stored/used consistently?

William Tanner · May 1, 2012

I have also had similar issue, I have a ticket open now which is being investigated.

Store CalcultateDateTime in a process data variable

ProcessData.dtSLA = Metastorm.Runtime.Types.DateTime.CurrentDate;
Metastorm.Runtime.Types.DateTime dtTemp = Mstm.CalculateDateTime(10,DateTimeUnits.Minutes, DateTimeDirection.After, Metastorm.Runtime.Types.DateTime.CurrentDate);

ProcessContext.UserError = Mstm.CalculateDuration(ProcessData.dtSLA, dtTemp, DateTimeUnits.Minutes);

This produces -590

Store CalculateDateTime in a local code block variable
ProcessData.dtSLA = Metastorm.Runtime.Types.DateTime.CurrentDate;
ProcessData.dtTemp = Mstm.CalculateDateTime(10,DateTimeUnits.Minutes, DateTimeDirection.After, Metastorm.Runtime.Types.DateTime.CurrentDate);

ProcessContext.UserError = Mstm.CalculateDuration(ProcessData.dtSLA, ProcessData.dtTemp, DateTimeUnits.Minutes);

This produces 10

The only difference between the two examples above is what you see in bold.

Brian Mellert · May 2, 2012

I didn't provide additional examples, but that is how I first came about it as well. I ended having to use SQL DATEDIFF after converting both values to strings instead of the BPM built in functions as I should be able to. Makes most "time in progress" items difficult to manage.

Jerome_Pearce · May 4, 2012

This is going to be a really painful issue.

Can the whole behaviour of dates, both in date time fields, time fields, grids, in server side code and in the database be fully documented? I seemingly have to work it all out myself by testing in every different environment.

The requirement to have the engine and database in the same time zone, and on exactly the same time, is also something that causes us endless pain. I have never come across it in other software.

William Tanner · May 6, 2012

In my example client machines and the server are in the same time zone. So I think the issue is the inconsistent conversion to UTC.

Brian Mellert · May 7, 2012

In my case, the database, engine and clients are all in the time zone as well. I haven't even gotten to checking clients in other time zones yet (and we have users in most time zones now).

It would be good if -- at a minimum -- the times and time offsets are consistent everywhere used -- though they should all work correctly everywhere. I see UTC in a grid, local in a field, ProcessContext.CurrentTime differs from a stored variable, etc. such a pain.

achopra · May 7, 2012

I have seen an issue where my grid was displaying UTC time - it was a grid and BO which had been created by the file migration utility from a v7 migration. I went in and messed around with the BO query and grid columns a bit (or maybe I re-created the grid from the BO?), and it started working properly (displayed times in the server's time zone). I'm not sure exactly which change fixed it, but I thought I'd pass that along in case this could be the situation with your grid.

Brian Mellert · May 8, 2012

Interesting "situation" with the grid. I'll have to tweak the BO it seems if your right, even thought the one I saw was not migrated. (Though it was originally created in V9.0.0 so maybe its related.)

The issue concerning me more deals with comparing CurrentTime with a stored database variable, or storing CurrentTime into a variable.

Brian Mellert · June 7, 2012

And I've now found similar issues extend into Timed events.

I have a process variable Hold_Until. There is also a timed event based upon this variable (5 minutes before Hold_Until).

I assign a future date/time into the variable ... for simplicity sake say 1 hour in the future (11 AM)

The timed event doesn't get an eWait record which should be 55 minutes from now (10:55 AM with those settings).

It doesn't seem to take unless its at least the UTC offset in the future.

While I can sometimes code around Process.CurrentTime being UTC and variables not, we have no control over how the engine processes this. Quite frustrating! :smileyfrustrated: Variables and the engine / ProcessContext times should be using the same offsets!

V9.1.2.2 (don't trust 9.1.3 yet though haven't checked out stabiltiy of hotfix 2 yet)

William Tanner · June 7, 2012

FYI, through the helpdesk I do have a defect number issed for this, so hopefully the fix will come shortly.

Ref# DEF20253

Brian Mellert · June 20, 2012

Thought I'd add info to the list, even though a defect is logged.

I just discovered that the date/time values are correct when the form first opens, but when refreshing a form (via a "Refresh" button that does nothing) without switching away from the form and back changes all times in grids to the offset. (e.g. a grid date is 6/20/2012 2:18PM when loaded, but when refreshed (refreshing BOs) the UTC offset is applied showing 6/20/2012 6:18PM instead. It works correctly if switching away and back to the firm again.

:smileysad: Hope all this date logic (and unrelated BO issues from 9.3.#) get fixed quickly. Users won't want to upgrade.

Jerome_Pearce · June 20, 2012

Thanks for sharing that, it is vital!

This is defintely a no-go for us. I will test in our test environments and see if I can reproduce it. Can you tell us if this is limited to one browser or not?

William Tanner · June 21, 2012

Another fun one to be aware of.....

ProcessData.FIELDWITHTIMEVALUE displays 12:00 PM on the form

Mstm.FormatDateTime(ProcessData.FIELDWITHTIMEVALUE,"hh:mm tt")

Produces 12:00 PM

however

ProcessData.FIELDWITHTIMEVALUE.ToString()

Produces 10:00 PM

Brian Mellert · June 21, 2012

We only use IE here, but I have seen the same situation apply to both IE7 and IE9. I have not tired other browsers since they are not part of the Firm PC build.

Jerome_Pearce · June 21, 2012

We must have some proper documentation on what to expect from each usage of Date variables, and what is stored in the database. The situation is becoming increasingly difficult to code 'around'.

It workked perfectly well for almost every situation before we had the time zone adjustment. Even then, as long as you turned that off (as it was set on by default), everything worked as expected.

My most important principle, The Principle of Least Astonishment, is constantly violated by the way Dates and Times behave in version 9.

Bill Tanner wrote:

Another fun one to be aware of.....

ProcessData.FIELDWITHTIMEVALUE displays 12:00 PM on the form

Mstm.FormatDateTime(ProcessData.FIELDWITHTIMEVALUE,"hh:mm tt")

Produces 12:00 PM

however

ProcessData.FIELDWITHTIMEVALUE.ToString()

Produces 10:00 PM

Aaron Van · November 30, 2012

Has anything come of this discussion? Bugfixes released? It just kind of ended without any follow up.

Brian Mellert · December 3, 2012

I haven't installed 9.2.0 yet (and plan on waiting for 9.2.1 due out this month supposedly) but no as of before that anyway.

I don't see anything in the 9.2.x notes implying anything has been addressed on this regard either.

Inconsistent Time Offset in Date Variables

Comments

Categories