FWD » Core Development » User Interface

Run the following 4GL example:

SESSION:SET-NUMERIC-FORMAT(",",".").
SESSION:DATE-FORMAT = "mdy".
DEFINE VARIABLE d AS DATETIME-TZ NO-UNDO.
DEFINE FRAME f d WITH SIDE-LABELS.
d:SCREEN-VALUE = "1/2/3".
ENABLE ALL WITH FRAME f.
WAIT-FOR CLOSE OF CURRENT-WINDOW.

This creates a frame with a DATETIME-TZ FILL-IN widget. The session numeric and date formats are explicitly set to eliminate locale-dependent variations in input parsing and DATETIME-TZ formatting. A non-unknown value is assigned via SCREEN-VALUE.

Behavior Comparison¶

The timezone offset displayed in the FILL-IN widget:

• OE: Reflects the current system locale timezone offset (e.g., +02:00 or -05:00).
• FWD: Always shows zero offset (+00:00), regardless of the actual system timezone.

Additional Observations¶

• In FWD, java.util.TimeZone.getDefault() correctly returns the system's timezone, indicating the issue lies in the widget's display logic rather than timezone detection.
• The mismatch is limited to the DATETIME-TZ FILL-IN widget display. The timezone offset in values formatted via STRING function is rendered correctly.

I used the following hand-written code:

      datetimetz dtz = new datetimetz("1/2/3");
      System.out.println(dtz.getIsoDate());

Because it does not require conversion or complex client/server communication. It prints

2003-01-02T00:00:00.000+02:00

showing that the current time offset is set in this case.

Please investigate how the screen value is set to d variable. There is probably something which makes it drop the offset or not taking it into consideration from the beginning.

Additional Observation

I've added a trigger, which prints the INPUT-VALUE attribute of the widget. The print contains the correct non-zero timezone.

The timezone information is lost during the DatetimeFormat.fromVar() conversion:

@Override
public Presentation fromVar(BaseDataType var)
throws DisplayFormatCheckException
{
   return new DatetimeBuf(new datetime(var));
}

Here, the var is a datetimetz instance containing timezone data, but the datetime constructor discards this information, resulting in a plain datetime value without the original timezone offset.