asLocalizedDateTime calculation differences

[adale]

I am having an issue with the "asLocalizedDateTime" intrinsic, and was wondering if it is something I am doing incorrectly, or if others have seen this and how to resolve.
Environment is IBM i Server, VL Web applications V15, epc 150050.
Both the IBM i Server, and my client PC, reflect the same current time (both in CST).

#wk_DT1, 2, 3, are defined as REFFLD #DATETIMEX

Initial value for wk_DT1 = 1900-01-01 15:00:00

The issue is that the VL Web Views/Dialogs convert to "local" time as UTC -6 hours to get CST (in my case).
But a VL RUP running from a server module converts to "local" time as UTC - 5 hours to get CST.

In my VL Dialog:
* Step 2 - convert to localized
#wk_DT2 := #wk_DT1.AsLocalizedDateTime
( wk_DT2 now = 1900-01-01 09:00:00 )

In my RUP:
#wk_DT3 := #wk_DT1.AsLocalizedDateTime
( wk_DT3 now = 1900-01-01 10:00:00 )

Why would the same intrinsic convert differently?

[BrendanB]

Arlyn,

first thing to check is :

Code: Select all

WRKSYSVAL QUTCOFFSET

WRKSYSVAL QTIMZON

make sure these reflect what you have on your PC:

namely:

-6000
CST

It may be that the IBM i has -5000 instead of -6000 and this would cause the calculations to be wrong.

B.

[adale]

The offset on the IBM is the difference, but it has to do with the daylight savings adjustment.
Our IBM is set for Time Zone QN0600CST2 Central Standard Time with offset of -06:00.
But currently we are in daylight savings time / mode, so the offset value is adjusted to -05:00 during CDT.

The time value is displayed in QTIME, and all scheduled jobs run on time as scheduled.

So, this brings up the question in regards to the "asLocalizedDateTime" intrinsic; how does this intrinsic when running from a web client adjust or deal with daylight savings? Is there a setting somewhere in VL that I need to set or adjust?

[BrendanB]

Arlyn,

when you are using a web client, the adjustment depends on the client PC (or mobile or tablet) and what it reports the offset from UTC to be.

this is why you can get different results on different PCs...

As you realize, a *datetime field should store in UTC...

then when you 'visualize' it you convert to a localized context.

you get even weirder results if you do something like: try showing a datetime that is in DECEMBER (non-DST period) but doing the conversion in a DST period... since there is no single way to determine *when* the timezone shifts, it will likely give you different values...

[belzswd]

Hi,

Related phenomenom arises when rendering a UTC time at the client that is in a different timezone than the server where UTC time has been determined (then returned to client). The client rendering misrepresents this field as it considers local (client) time when rendering the UTC time delivered from the server - Eg - In this example - Client Timezone is AEST (in QLD); Server Timezone is AEDT (in NSW) -

QLD_Times_01.jpg (5.99 KiB) Viewed 17898 times

The field labelled Universal-Time (Server) - was determined server-side as - #PMR_ServerTime := #SR_Now.Now.AsUniversalDateTime (but incorrectly rendered).

Can the client (web-page/field) properties be altered to render correctly?

Regards, AB

[BrendanB]

Anthony,

The problem really is:

if stored in UTC on a server as 17/10/2024 22:14:49 UTC 0

when converting to display do you want to see it UTC +11 or UTC +10?

if you ALWAYS want to show the time as UTC +11, then you should convert to a display string ON THE SERVER. (since it is in UTC+11)...

if you are also inputting the values, then if you store the UTC Offset that it should display, then you should be able to output a display string to the client as 'local' by applying the relevant UTC Offset.

Brendan.