Hello -- Im am in easten time and we are now in daylite time (march 2016) -- the time('o') function
now is returning -3 hours from UTC -- when it should be -4 -- did I miss something with this function
Hello -- Thanks for confirming what I found .... I wrote a trivial program in C to write out
the local date/time and the UTC date/time using the standard C library calls -- I compiles
ok under windows
I added an option to specify a strftime format on the command line -- I can then use rexx BIF date and time to convert the timestamps into seconds and computer the difference -- so the C code generate a
time stamp in the form
It actually seems worse now. I know that most of this depends upon the O/S, but now it looks like time('T') is off, as well as the offset. When I convert TIME('T') to today's hours:minutes:seconds I get what timeanddate.com says is UTC plus 1 hour.
21:20:48TIME('T')time14:20:47Localtime-5offset?
At the time I ran this, timeanddate.com said UTC was about 20:20.
It's also slightly disconcerting that TIME('T') and TIME('L") have a difference in the seconds position, since TRL2 says "The first call to DATE or TIME in one clause causes a record of the time to be made which is then used for all calls to these functions within that clause." and even if the arguments between PARSE VALUE and WITH are not considered one "clause", it would be a remarkable coincidence for the seconds value to change across consecutive calls to TIME. Especially if the second call returns an earlier time than the first....
I suspect the TIME('T') calculation rounds up, whereas all other variations of TIME() truncate.
numeric digits 20 /* must be > 9 to handle arithmetic with TIME('T') results */
secpermin = 60
secperhr = secpermin * 60
secperday = secperhr * 24
parse value time('T') time('O')/3600e6 time('L') with unixt offsethr hh ':' mm ':' ss '.' .
parse value unixt%secperday unixt//secperday with days partday
parse value partday%secperhr partday//secperhr with hours parthour
parse value parthour%secpermin parthour//secpermin with minutes seconds
say hours':'right(minutes,2,'0')':'right(seconds,2,'0') 'TIME('"'T'"') time'||.endofline||right(hh,2,'0')':'right(mm,2,'0')':'right(ss,2,'0') 'Local time'||.endofline||offsethr 'offset?'
Last edit: Paul Kislanko 2017-03-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello -- Yes it seems that there is an issue with the utc offset and the dayligjht time BIF -- here in the usa daylite time starts the second sunday in march and ends the first sunday in november -- using the
time('t') and time('s') info I was able to compute the utc offset and using the rules for daylite time I was able to write a simple function to find out if the date was in the daylite range -- Here is a short
script to computer the utc offset and daylite time flag
The utcoffset exec does give the correct results, so thank you!
But here's a question.
I don't think the statement
procedure expose (exposed)
actually does anything. According to the "rules", it should be
procedure expose exposed (exposed)
I know in order to make all of the variables listed in my "globaldata"
variable list available I have to expose globaldata before (globaldata)
procedure expose globaldata (globaldata)
The Regina.doc touches on this with the discussion about order of exposure,
but does not explicitly mention how it applies to the (variable containing
list of variables) syntax.
From: Frank [mailto:fpefpe@users.sf.net]
Sent: Friday, March 24, 2017 1:54 PM
To: [regina-rexx:bugs]476@bugs.regina-rexx.p.re.sf.net
Subject: [regina-rexx:bugs] #476 utc offset time BIF
Hello -- Yes it seems that there is an issue with the utc offset and the
dayligjht time BIF -- here in the usa daylite time starts the second sunday
in march and ends the first sunday in november -- using the
time('t') and time('s') info I was able to compute the utc offset and using
the rules for daylite time I was able to write a simple function to find out
if the date was in the daylite range -- Here is a short
script to computer the utc offset and daylite time flag
Status: open
Group: v3.9.1
Created: Tue Mar 15, 2016 01:59 AM UTC by Frank
Last Updated: Thu Mar 23, 2017 08:42 PM UTC
Owner: nobody
Hello -- Im am in easten time and we are now in daylite time (march 2016) --
the time('o') function
now is returning -3 hours from UTC -- when it should be -4 -- did I miss
something with this function
yes -- I see that issue -- thanks for pointing that out ... I guess that
the contents of the variable "exposed" are exposed before "procedure" is
processed ..
The command shell that I use will load rexx as a scripting alternative ...
that is why the code is saving / read env vars
The utcoffset exec does give the correct results, so thank you!
But here's a question.
I don't think the statement
procedure expose (exposed)
actually does anything. According to the "rules", it should be
procedure expose exposed (exposed)
I know in order to make all of the variables listed in my "globaldata"
variable list available I have to expose globaldata before (globaldata)
procedure expose globaldata (globaldata)
The Regina.doc touches on this with the discussion about order of exposure,
but does not explicitly mention how it applies to the (variable containing
list of variables) syntax.
From: Frank [mailto:fpefpe@users.sf.net]
Sent: Friday, March 24, 2017 1:54 PM
To: [regina-rexx:bugs] 476@bugs.regina-rexx.p.re.sf.net
Subject: [regina-rexx:bugs] #476 utc offset time BIF
Hello -- Yes it seems that there is an issue with the utc offset and the
dayligjht time BIF -- here in the usa daylite time starts the second sunday
in march and ends the first sunday in november -- using the
time('t') and time('s') info I was able to compute the utc offset and using
the rules for daylite time I was able to write a simple function to find
out
if the date was in the daylite range -- Here is a short
script to computer the utc offset and daylite time flag
Status: open Group: v3.9.1 Created: Tue Mar 15, 2016 01:59 AM UTC by Frank Last Updated: Fri Mar 24, 2017 07:53 PM UTC Owner: nobody
Hello -- Im am in easten time and we are now in daylite time (march 2016)
-- the time('o') function
now is returning -3 hours from UTC -- when it should be -4 -- did I miss
something with this function
Hi, I am using v3.9.1 and it seems to be present in Windows but not in Linux. Here is what I'm running in Rexx in the Eastern timezone and the results on Windows 10:
say time()
say time('n', time('t'), 't')
22:28:13
23:28:13
The same two lines on CentOS7, also v3.9.1 - as you can see the results match:
22:29:22
22:29:22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Likewise, here in the North American "Mountain" time zone the offset shows -5 hours and the correct value during DST is -6.
WIN64 REXX-Regina_3.9.1(MT) 5.00 5 Apr 2015
I actually never checked time('o') during standard time, so I can't tell if this is a Regina or Windows issue.
Hello -- Thanks for confirming what I found .... I wrote a trivial program in C to write out
the local date/time and the UTC date/time using the standard C library calls -- I compiles
ok under windows
I added an option to specify a strftime format on the command line -- I can then use rexx BIF date and time to convert the timestamps into seconds and computer the difference -- so the C code generate a
time stamp in the form
ldate = '20160301'; ltime = '12:00:00'
then I can use
seconds = date( 'b', ldate, 's' ) * 86400 + time( 's', ltime, 'n' )
86400 is the number of seconds in a day
This works and I get the correct UTC offset
It actually seems worse now. I know that most of this depends upon the O/S, but now it looks like time('T') is off, as well as the offset. When I convert TIME('T') to today's hours:minutes:seconds I get what timeanddate.com says is UTC plus 1 hour.
At the time I ran this, timeanddate.com said UTC was about 20:20.
It's also slightly disconcerting that TIME('T') and TIME('L") have a difference in the seconds position, since TRL2 says "The first call to DATE or TIME in one clause causes a record of the time to be made which is then used for all calls to these functions within that clause." and even if the arguments between PARSE VALUE and WITH are not considered one "clause", it would be a remarkable coincidence for the seconds value to change across consecutive calls to TIME. Especially if the second call returns an earlier time than the first....
I suspect the TIME('T') calculation rounds up, whereas all other variations of TIME() truncate.
numeric digits 20 /* must be > 9 to handle arithmetic with TIME('T') results */ secpermin = 60 secperhr = secpermin * 60 secperday = secperhr * 24 parse value time('T') time('O')/3600e6 time('L') with unixt offsethr hh ':' mm ':' ss '.' . parse value unixt%secperday unixt//secperday with days partday parse value partday%secperhr partday//secperhr with hours parthour parse value parthour%secpermin parthour//secpermin with minutes seconds say hours':'right(minutes,2,'0')':'right(seconds,2,'0') 'TIME('"'T'"') time'||.endofline||right(hh,2,'0')':'right(mm,2,'0')':'right(ss,2,'0') 'Local time'||.endofline||offsethr 'offset?'Last edit: Paul Kislanko 2017-03-23
Hello -- Yes it seems that there is an issue with the utc offset and the dayligjht time BIF -- here in the usa daylite time starts the second sunday in march and ends the first sunday in november -- using the
time('t') and time('s') info I was able to compute the utc offset and using the rules for daylite time I was able to write a simple function to find out if the date was in the daylite range -- Here is a short
script to computer the utc offset and daylite time flag
The utcoffset exec does give the correct results, so thank you!
But here's a question.
I don't think the statement
procedure expose (exposed)
actually does anything. According to the "rules", it should be
procedure expose exposed (exposed)
I know in order to make all of the variables listed in my "globaldata"
variable list available I have to expose globaldata before (globaldata)
procedure expose globaldata (globaldata)
The Regina.doc touches on this with the discussion about order of exposure,
but does not explicitly mention how it applies to the (variable containing
list of variables) syntax.
From: Frank [mailto:fpefpe@users.sf.net]
Sent: Friday, March 24, 2017 1:54 PM
To: [regina-rexx:bugs] 476@bugs.regina-rexx.p.re.sf.net
Subject: [regina-rexx:bugs] #476 utc offset time BIF
Hello -- Yes it seems that there is an issue with the utc offset and the
dayligjht time BIF -- here in the usa daylite time starts the second sunday
in march and ends the first sunday in november -- using the
time('t') and time('s') info I was able to compute the utc offset and using
the rules for daylite time I was able to write a simple function to find out
if the date was in the daylite range -- Here is a short
script to computer the utc offset and daylite time flag
Attachments:
https://sourceforge.net/p/regina-rexx/bugs/_discuss/thread/bb3c1648/4eac/at tachment/utcoffset.cmd (2.9 kB; application/octet-stream)
[bugs:#476] https://sourceforge.net/p/regina-rexx/bugs/476/ utc offset
time BIF
Status: open
Group: v3.9.1
Created: Tue Mar 15, 2016 01:59 AM UTC by Frank
Last Updated: Thu Mar 23, 2017 08:42 PM UTC
Owner: nobody
Hello -- Im am in easten time and we are now in daylite time (march 2016) --
the time('o') function
now is returning -3 hours from UTC -- when it should be -4 -- did I miss
something with this function
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/regina-rexx/bugs/476/
To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/
yes -- I see that issue -- thanks for pointing that out ... I guess that
the contents of the variable "exposed" are exposed before "procedure" is
processed ..
The command shell that I use will load rexx as a scripting alternative ...
that is why the code is saving / read env vars
glad to help
Frank Esposito
On Sun, Apr 2, 2017 at 7:08 PM, Paul Kislanko jpk77@users.sf.net wrote:
--
Frank Esposito
Related
Bugs: #476
Hi, I am using v3.9.1 and it seems to be present in Windows but not in Linux. Here is what I'm running in Rexx in the Eastern timezone and the results on Windows 10:
say time()
say time('n', time('t'), 't')
22:28:13
23:28:13
The same two lines on CentOS7, also v3.9.1 - as you can see the results match:
22:29:22
22:29:22