Projects/Absolute DateTime Reference/Technical Documentation

Contents 1 Absolute DateTime Reference - Technical Documentation 1.1 Database changes in Core 1.2 New files in Core 1.3 Database changes in org.openbravo.client.kernel 1.4 New files in org.openbravo.client.kernel 1.5 Logic related explanation

Absolute DateTime Reference - Technical Documentation

Database changes in Core

AD_Reference:

• Absolute Time: Time reference, where the displayed time is exactly the same that is stored in the database.

There is not any kind of timezone conversion. The stored time does not have timezone.

• Absolute DateTime: DateTime reference, where the displayed date-time is exactly the same that is stored in the database.

There is not any kind of timezone conversion. The stored date-time does not have timezone.

New files in Core

• src/org/openbravo/base/model/domaintype/AbsoluteDateTimeDomainType.java

• src/org/openbravo/base/model/domaintype/AbsoluteTimeDomainType.java

Database changes in org.openbravo.client.kernel

UIDefinition:

• org.openbravo.client.kernel.reference.AbsoluteTimeUIDefinition

• org.openbravo.client.kernel.reference.AbsoluteDateTimeUIDefinition

New files in org.openbravo.client.kernel

• src/org/openbravo/client/kernel/reference/AbsoluteTimeUIDefinition.java

• src/org/openbravo/client/kernel/reference/AbsoluteDateTimeUIDefinition.java

Logic related explanation

The logic applied to the new "Absolute Time" and "Absolute DateTime" references is similar than the applied to the standard "Time" and "DateTime" references with the following differences:

• When passing the time/datetime from the client to the server, the value is passed as it is read from the database, so there is no UTC conversion.
• When receiving a value from the client, it is stored as it comes from the client without any UTC conversion.
• The big change is in the client side: When the value reach the client, Smartclient expects that the value that have been received is in UTC and then it converts it to client timezone. This conversion is needed because when the value is sent to the server, the change is reversed, so it does the opposite conversion transforming it from client timezone to UTC.
• The implemented solution makes that the user sees in the screen the value that has come from the server instead of the value converted to the client timezone, although internally, the real value it has been converted from UTC to client timezone.
• To do the conversion between what he user sees and operates and what it is really stored internally as the field value, the functions "mapValueToDisplay" and "mapDisplayToValue" are used in the case of "Absolute Time" reference and "parseEditorValue" and "formatEditorValue" are used in the case of "Absolute DateTime" reference. Ideally, both cases should use "parseEditorValue" and "formatEditorValue", but due to a Smartclient issue, "Time" reference doesn't accept these ones.