Bug. Timestamp with separate time (5.8)

Rennur

I have a rule that executes when the timestamp attribute with separate time is defined. Unlike in previous versions, the rule now executes as soon as the date part is defined.

Like previous version, the rule should execute when both the date and time are defined.
My other timestamp with separate time that gets defined with TIME_ADD rule gets executed prematurely now.

Cheers

rocketman

In mysql terms, a timestamp field (attribute) is a single entity comprising date and time information. I would have thought that defining any part either date or time would constitute the timestamp attribute as being "defined"

So - put 01-0-2014 into a timestamp attribute and it will become defined (according to the mysql manual, if you do that then the time element will by default be set as 00:00

Basically what I'm saying is that if earlier versions treated the time element differently, then it is those earlier versions that were behaving incorrectly

Rennur

Basically what I'm saying is that if earlier versions treated the time element differently, then it is those earlier versions that were behaving incorrectly

I must disagree.

I would have thought that defining any part either date or time would constitute the timestamp attribute as being "defined"

So - put 01-0-2014 into a timestamp attribute and it will become defined (according to the mysql manual, if you do that then the time element will by default be set as 00:00

The timestamp is not stored in the MySQL database until the form is saved, we are merely selecting the date options from the form not the stored value from a database.
AwareIM rules and functions are not directly related to MySQL, therefore Aware was coded to execute the rule once both the date & time is defined (not saved).

This is a bug.

Cheers

aware_admin

This is how Aware IM works now. An empty time value is considered 00:00.

Rennur

This is how Aware IM works now.

Not for the better, was there no consideration for apps that have been already programmed before this change?

Empty time value is irrelevant.
00:00 is not always in the time range, if time range is defined.
You get a nice little red outline around the time box, not great for UX.

DEFINED means defining both the DATE and TIME of this attribute, otherwise it is NOT DEFINED.
It is only partly defined.

Of course there are always workarounds for something that worked fine before but don't understand why this had to change.

-1

Rennur

I'm not done,

another BO 'Waiting Time' calculates a duration (dynamically) of the truck that has been waiting onsite and is based on 2 timestamp attributes.
This duration is now calculated as soon as the date in the 2nd timestamp is defined.

The result is that the system reads the time of the second timestamp as 00:00 and spits out an incorrect duration (until the right time is selected).
It also populates rate & the total amount ($) attribute that are based on this duration with the wrong information. Again, until the right time is selected.

Nothing should be calculated and execute until everything is DEFINED, not PART DEFINED.

Sorry everyone about my irate post but If it ain't broke, don't fix it.

RocketRod

I can see what Rennur is getting at.

Keeping it simple the timestamp attribute is one value consisting of a date part and a time part. In the db it's one field. So just because it's split on the screen for a user to enter the parts separately, it should not be considered entered/defined until both parts are completed.

Having said that, I can see though from supports point of view that this may be very difficult to achieve as a user may enter the date part, move to another field on the screen then move back to the time part?

I guess I'm not helping the discussion in that I can see both sides of the coin and don't have a practical answer in how to achieve it. In any event I'm now going back through my apps as I use split times everywhere and wasn't aware of this! So thanks Rennur for pointing it out.

Cheers Rod

Rennur

It's not difficult to achieve, it worked fine. It has already been achieved and now it's changed.

Rennur

Hi Support,

Will this be reverted back to normal or do I need to workaround it?

Cheers

Rennur

This has really screwed up the user entry and I'm now getting complaints.
Dynamic rules regarding timestamps with separate time cannot be set properly now. There are multiple issues now that this has been changed.

Support, can you please explain to us the reasoning behind the change to timestamps with separate time?

Rennur

I guess no one uses separate time with calculated values in their app.

Anyhow, this will remain broke, causing unnecessary UI, rule development and workaround headaches.

I guess we'll never know why this had to be tempered with.
Must be a closely guarded trade secret.

Rant over 😉

hpl123

Rennur (and support),
Having options to work with time separately in rules is something I would use.
Thanks