#1313 Time('offset') on ooRexx 4.1.3 Linux Not Handing Daylight Savings

[Norbert]

I recently compiled and installed ooRexx 4.1.3 64bit on a CentOS 5.5 system. I also have ooRexx 4.1.1 running on Windows. Below are the values returned by various functions - Time('o') on Windows adjusts for Daylight Savings but on Linux always shows the offset for Standard Time.

OS	Date() Time()	Time('t')	Time ('o')	System Date
Windows	1 Nov 2014 20:00:00	1414872000	-14400000000
Linux	1 Nov 2014 20:00:01	1414872001	-18000000000	Sat Nov 1 20:00:01 EDT 2014
Windows	2 Nov 2014 04:00:09	1414900809	-18000000000
Linux	2 Nov 2014 04:00:01	1414900801	-18000000000	Sun Nov 2 04:00:01 EST 2014

This problem cropped in in an application that needs to adjust the local Time('t') to reflect UTC. I have also seen this problem on ARM systems.

[Thanny]

This bug is still present in 4.2.0.

I noticed it in the "offset" method of the datetime class.

[Erich]

Committed 5.0 code fix with revision [r11326]

On Linux, we now should the the following:

OS	date() time()	time('t')	time('o')	System Date
LINUX	29 Oct 2017 00:00:00	1509235200	7200000000	Sun 29 Oct 00:00:00 CEST 2017
LINUX	29 Oct 2017 04:00:00	1509249600	3600000000	Sun 29 Oct 04:00:00 CET 2017

Tests and feeedback welcome!!
Thanks for reporting.

[Erich]

I noticed it in the "offset" method of the datetime class

Above fixes is just the time('o') issue.

ooRexx currently uses a single (the current) timezone offset for all .DateTime instances.
Not sure, if .DateTime arithmetic could handle specific offsets for each instance.
If we think that's an issue, this will have to go into s separate ticket.

[Rick McGuire]

The datetime instances should be performing arithmetic using a timestamp that has been adjusted to UTC time, so objects for the same UTC in different timezones should be considered equal.

[Erich]

I'm still not sure whether the following is a bug.

• Today (23 Oct, summer time in the EU) both a summer-time timestamp and a winter-time timestamp show a timezone offset of two
• A week later (30 Oct, winter time in the EU) both these timestamps show a timezone offset of one

Should the 23 Oct - timestamp always show an offset of two, and 30 Oct always one? (I believe this is how file time stamp handling works)

WARNING: running the following Windows-only code will change your Windows system time!

do day over (23, 30)
  "date" day".10.2017"
  say date() time("o") / 1e6 .DateTime~new(2017, 10, 23)~offset,
     .DateTime~new(2017, 10, 30)~offset
end
"date 23.10.2017"

will output

23 Oct 2017 7200 02:00:00.000000 02:00:00.000000
30 Oct 2017 3600 01:00:00.000000 01:00:00.000000

[Rony G. Flatscher]

As this program runs on MET, which is UCT+1, unless summer savings time is in effect which would be UCT+2.

Winter time will come up with the last Sunday in October (starting October 29th), if not mistaken, so

• October 23rd should be: UCT+2
• October 30th should be: UCT+1

[Rony G. Flatscher]

Here a version that uses .dateTime only:

say "--- with offset, reflecting summer savings time:"
dt1=.dateTime~new(2017,10,23,14,00,14,1,120) -- 120 minutes (summer savings time)
dt2=.dateTime~new(2017,10,30,14,00,14,1, 60) --  60 minutes (winter time)
say "dt1:    " dt1 dt1~offset
say "dt2:    " dt2 dt2~offset
say "dt2-dt1:" dt2-dt1
say
say "--- no offset, so defaults by ooRexx (current offset):"
dt3=.dateTime~new(2017,10,23,14,00,14,1)
dt4=.dateTime~new(2017,10,30,14,00,14,1)
say "dt3:    " dt3 dt3~offset
say "dt4:    " dt4 dt4~offset
say "dt4-dt3:" dt4-dt3

Running the above yields (note the difference of one hour when doing the subtraction with explicit UTC offsets):

--- with offset, reflecting summer savings time:
dt1:     2017-10-23T14:00:14.000001 02:00:00.000000
dt2:     2017-10-30T14:00:14.000001 01:00:00.000000
dt2-dt1: 7.01:00:00.000000

--- no offset, so defaults by ooRexx (current offset):
dt3:     2017-10-23T14:00:14.000001 02:00:00.000000
dt4:     2017-10-30T14:00:14.000001 02:00:00.000000
dt4-dt3: 7.00:00:00.000000

[Erich]

To answer my own question:
No, it's not a bug, as rexxref states "The default offset is the current system timezone offset."

So, no more fixes required.
I'll keep this open until after the EU DST change, to allow for any tests results to be reported