(which has as element 7 the UTC-offset in seconds. I use this element to get the local UTC offset).
The local date is here ...
[*] ... correct on Mac.
Shows for example for my time zone (incl. +1 hour DST)
[2016, 10, 4, 16, 53, 37, 7200]
the LCS internet date is accordingly
Tue, 4 Oct 2016 16:53:37 +0200
the universal date yields correctly
[2016, 10, 4, 14, 53, 37, 0]
[*] ... wrong on Windows and Linux.
Shows for example for my time zone (incl. +1 hour DST)
[2016, 10, 4, 16, 53, 37, -3600]
the LCS internet date is correct
Tue, 4 Oct 2016 16:53:37 +0200
the universal date yields correctly
[2016, 10, 4, 14, 53, 37, 0]
Summary.
Elements 1 to 6 of the local date are correct, but the offset element is 'wrong'.
When I change the time zone it becomes revealed:
The offset displayed on Windows and Linux is (-1)*UTC offset (ignoring DST).
For example for UTC -0300 I get on Windows and Linux: +0300 (ignoring DST),
in seconds UTC -10800 changes on Windows and Linux to 10800 (ignoring DST).
May be this is influenced by the virtual machine I use for testing?
Anyway, the date is taken from network time servers, on all three platforms. And they *all* display the same "the universal date" (from LCB).
Is it a "bug"?
Snippet for testing in LCB
Code: Select all
public handler OnTimer()
log the local date
log the universal date
variable tU as Number
put the universal time into tU
log tU
schedule timer in (the ceiling of tU - tU) seconds
end handler
public handler OnOpen()
schedule timer in 0.1 seconds
end handler
public handler OnClose()
cancel timer
end handler