ooRexx 4.0.0 using date("F or T") and time("F or T")
Jeremy Nicoll - news posts
And that date("F") and time("F") return the same value?
I think I'd have expected the date() functions to return a value for time
00:00:00 on today's date, and the time() calls to be for the current time on
today's date.
As it is, the result of date("F") and date("T") are now different at various
times in a particular day, which is not the case for - say - date("B").
--
Jeremy C B Nicoll - my opinions are my own.
Email sent to my from-address will be deleted. Instead, please reply
to newsre...@wingsandbeaks.org.uk replacing "nnn" by "284".
Jeremy Nicoll - news posts
> Is it right that date("T") and time("T") return the same value?
Also, this code:
do h = 0 to 23
hhcmmcss = right(h,2,"0") || ":01:01"
say "Time('T',"hhcmmcss",'N') is:" time("T",hhcmmcss,"Normal")
end
produces:
Time('T',00:01:01,'N') is: -62135596739
Time('T',01:01:01,'N') is: -62135593139
Time('T',02:01:01,'N') is: -62135589539
Time('T',03:01:01,'N') is: -62135585939
Time('T',04:01:01,'N') is: -62135582339
Time('T',05:01:01,'N') is: -62135578739
Time('T',06:01:01,'N') is: -62135575139
Time('T',07:01:01,'N') is: -62135571539
Time('T',08:01:01,'N') is: -62135567939
Time('T',09:01:01,'N') is: -62135564339
Time('T',10:01:01,'N') is: -62135560739
Time('T',11:01:01,'N') is: -62135557139
Time('T',12:01:01,'N') is: -62135553539
Time('T',13:01:01,'N') is: -62135549939
Time('T',14:01:01,'N') is: -62135546339
Time('T',15:01:01,'N') is: -62135542739
Time('T',16:01:01,'N') is: -62135539139
Time('T',17:01:01,'N') is: -62135535539
Time('T',18:01:01,'N') is: -62135531939
Time('T',19:01:01,'N') is: -62135528339
Time('T',20:01:01,'N') is: -62135524739
Time('T',21:01:01,'N') is: -62135521139
Time('T',22:01:01,'N') is: -62135517539
Time('T',23:01:01,'N') is: -62135513939
LesK
http://www.oorexx.org/docs/rexxref/x23579.htm#BIFDATE and:
http://www.oorexx.org/docs/rexxref/x23579.htm#BIFTIME
Les (Change Arabic to Roman to email me)
LesK
smaller as the clock goes forward?
Les (Change Arabic to Roman to email me)
Jeremy Nicoll - news posts
> That certainly looks wrong! A negative number that gets
> smaller as the clock goes forward?
Having experimented more, I think it's right.
Time('T',03:01:01,'N') is: -62135585939
means the number of ticks since (ie before) 1st Jan 1970 for the implied
timestamp 03:01:01 on 1st Jan 0001.
However I think all of this violates the principle of least surprise [as
Mike Cowlishaw put it: "Could there be a high astonishment factor associated
with this feature?"] and consistency that was meant to pervade REXX. For
example:
time("H") time("M") time("S")
all provide counts of the numbers of time-intervals past midnight of a
particular time. So why doesn't time("T") provide a tick-count since
midnight and time("F") provide a microsecond count since midnight?
It feels completely wrong to me for a date function to pay attention to the
time of day on which it is called. This is especially the case when you
consider that for date /conversions/ an implicit 00:00:00.000000 time IS
used.
I do not expect, given:
date_s = date("S") /* eg: "20091108" */
date_t = date("T") /* 86400 possible answers each day */
that
say date("T",date_s,"Sorted") /* only one answer */
will print a value that's almost always different from date_t.
I'm really surprised <whoever> chose to do it this way. To my mind both
date() and time() should have remained day-specific or time-specific without
mixing dates into time values or times into date values.
There should have been a new BIF called, say, timestamp() which implemented
the "T" and "F" timestamp options.
LesK
Les (Change Arabic to Roman to email me)
Jeremy Nicoll - news posts wrote:
> LesK <5mr...@tampabay.rr.com> wrote:
>
>> That certainly looks wrong! A negative number that gets
>> smaller as the clock goes forward?
>
> Having experimented more, I think it's right.
>
> Time('T',03:01:01,'N') is: -62135585939
>
> means the number of ticks since (ie before) 1st Jan 1970 for the implied
> timestamp 03:01:01 on 1st Jan 0001.
Huh? How do you equate 'since' to 'before'? They have
opposite meanings! The 2nd and 3rd arguments specify the
local time, *not* the time on 1 Jan 001 as is used for 'Full'
>
>
>
> However I think all of this violates the principle of least surprise [as
> Mike Cowlishaw put it: "Could there be a high astonishment factor associated
> with this feature?"] and consistency that was meant to pervade REXX. For
> example:
>
> time("H") time("M") time("S")
>
> all provide counts of the numbers of time-intervals past midnight of a
> particular time. So why doesn't time("T") provide a tick-count since
> midnight and time("F") provide a microsecond count since midnight?
They extend the Time function to make it more robust. If
you don't need the additional capability, simply don't use it.
>
>
>
> It feels completely wrong to me for a date function to pay attention to the
> time of day on which it is called. This is especially the case when you
> consider that for date /conversions/ an implicit 00:00:00.000000 time IS
> used.
But it is consistent with the extended Time functions.
Jeremy Nicoll - news posts
> Jeremy Nicoll - news posts wrote:
> > LesK <5mr...@tampabay.rr.com> wrote:
> >
> >> That certainly looks wrong! A negative number that gets
> >> smaller as the clock goes forward?
> >
> > Having experimented more, I think it's right.
> >
> > Time('T',03:01:01,'N') is: -62135585939
> >
> > means the number of ticks since (ie before) 1st Jan 1970 for the implied
> > timestamp 03:01:01 on 1st Jan 0001.
> Huh? How do you equate 'since' to 'before'?
Well look, if I said that there were nn ticks between 1970 and a time, I
think you'd understand that the time was AFTER 1970. If I said -nn, it'd
have to mean something else wouldn't it?
> They have opposite meanings!
I was trying to explain that I thought the negative result was because the
calculation had implicitly been for a time on a day /before/ 1970.
> The 2nd and 3rd arguments specify the local time, *not* the time on 1 Jan
> 001 as is used for 'Full'.
By 'local time', do you mean 'on the day on which the exec is running'?
If so, you'd get a different answer from: Time('T',03:01:01,'N') depending
on what day the exec ran...
I posted my question on the 7th November; then I got: -62135585939
Now running the same thing, on 9th Nov, I get: -62135585939
That is, the same number. How do you explain that?
Yes, local time, but on what day? Ticks calculates an elapsed number of
seconds since (that is, after, if it is positive) 1970.
I coded: Time('T',03:01:01,'N') and got: -62135585939
You're saying that this means do the calculation for localtime 03:01:01 (so
it would be for the day on which I ran the exec)?
Would that be the same result as you'd get from: time("T") issued at that
time? It seems to me that that's what you're saying you think it is.
Unfortunately, if I issue: time("T") now (10:22pm or so), I get 1257805291
This is hugely different from the result of: Time('T',03:01:01,'N') whereas
if they were implicitly for the same day as I think you're suggesting, then
the values would need to be a bit over 19 hour's worth of ticks different
from each other, that is:
You'd expect a difference of approx 19 * 60 * 60 = 68400
+ 19 * 60 1140
ie about 70,000.
It's worth writing those numbers out with commas:
Time('T',03:01:01,'N') was: -62,135,585,939
Time('T') is: 1,257,805,291
Huge difference! Try running this:
aa = 1257805291
bb = -62135585939
diffsecs = aa - bb
diffmins = diffsecs % 60
diffhors = diffmins % 60
diffdays = diffhors % 24
diffyers = diffdays % 365
say "AA:" right(aa,15)
say "BB:" right(bb,15)
say
say "Difference, AA-BB is:" right( diffsecs,15) " secs"
say " ie roughly:" right( diffmins,15) " min"
say " ie roughly:" right( diffhors,15) " hours"
say " ie roughly:" right( diffdays,15) " days"
say " ie roughly:" right( diffyers,15) " years"
I get:
AA: 1257805291
BB: -62135585939
Difference, AA-BB is: 63393391230 secs
ie roughly: 1056556520 min
ie roughly: 17609275 hours
ie roughly: 733719 days
ie roughly: 2010 years
so I think I'm right when I say that one of these times was indeed for the
first of January in 0001. What do you think now?
> > However I think all of this violates the principle of least surprise [as
> > Mike Cowlishaw put it: "Could there be a high astonishment factor
> > associated with this feature?"] and consistency that was meant to
> > pervade REXX. For example:
> >
> > time("H") time("M") time("S")
> >
> > all provide counts of the numbers of time-intervals past midnight of a
> > particular time. So why doesn't time("T") provide a tick-count since
> > midnight and time("F") provide a microsecond count since midnight?
> They extend the Time function to make it more robust. If
> you don't need the additional capability, simply don't use it.
(Why don't you put blank lines into your replies? It makes it hard to
read.)
> > It feels completely wrong to me for a date function to pay attention to
> > the time of day on which it is called. This is especially the case when
> > you consider that for date /conversions/ an implicit 00:00:00.000000
> > time IS used.
> But it is consistent with the extended Time functions.
The point is that it's inconsistent with some of the functions. Because it
is "some" rather than "all", that is in itself inconsistent.
LesK
Les (Change Arabic to Roman to email me)
Jeremy Nicoll - news posts wrote:
> LesK <5mr...@tampabay.rr.com> wrote:
>
>
>> Jeremy Nicoll - news posts wrote:
>>> LesK <5mr...@tampabay.rr.com> wrote:
>>>
>>>> That certainly looks wrong! A negative number that gets
>>>> smaller as the clock goes forward?
>>> Having experimented more, I think it's right.
>>>
>>> Time('T',03:01:01,'N') is: -62135585939
>>>
>>> means the number of ticks since (ie before) 1st Jan 1970 for the implied
>>> timestamp 03:01:01 on 1st Jan 0001.
>
>> Huh? How do you equate 'since' to 'before'?
>
> Well look, if I said that there were nn ticks between 1970 and a time, I
> think you'd understand that the time was AFTER 1970. If I said -nn, it'd
> have to mean something else wouldn't it?
Yes, I agree it would *but* that's not what the description
says!
>
>
>> They have opposite meanings!
>
> I was trying to explain that I thought the negative result was because the
> calculation had implicitly been for a time on a day /before/ 1970.
>
>
>> The 2nd and 3rd arguments specify the local time, *not* the time on 1 Jan
>> 001 as is used for 'Full'.
>
> By 'local time', do you mean 'on the day on which the exec is running'?
Yes.
>
> If so, you'd get a different answer from: Time('T',03:01:01,'N') depending
> on what day the exec ran...
I would hope so.
>
> I posted my question on the 7th November; then I got: -62135585939
>
> Now running the same thing, on 9th Nov, I get: -62135585939
>
> That is, the same number. How do you explain that?
The result doesn't match the description. One or the other
would seem to be in error.
>
>
>
> Yes, local time, but on what day? Ticks calculates an elapsed number of
> seconds since (that is, after, if it is positive) 1970.
>
>
> I coded: Time('T',03:01:01,'N') and got: -62135585939
>
> You're saying that this means do the calculation for localtime 03:01:01 (so
> it would be for the day on which I ran the exec)?
>
> Would that be the same result as you'd get from: time("T") issued at that
> time? It seems to me that that's what you're saying you think it is.
Yes, that's what the description tells me. However, it (or
my understanding of it)
is obviously wrong! Here is an example that I think should
produce identical
results:
say time('T') time('T',time(),'N')
exit
but it doesn't! I get:
1257811886 -62135596114
RATS! Should have read further... all the way at the bottom
it says:
When requesting times be converted to Full or Ticks format,
a date value of 1 January 0001 is used for the conversion.
A time stamp for a time and date combination can be created
by combining a value from Date('F') for the time of day.
numeric digits 18 -- needed to add the timestamps
timestamp = date('f, '20072301', 'S') + time('f',
'08:14:22', 'N')
That explains everything!
I think you're right, but then what good is time('F')
except to increase the accuracy?
Given the magical, under the covers, change of date, what
good is time('T') conversion?
>
>
>>> However I think all of this violates the principle of least surprise [as
>>> Mike Cowlishaw put it: "Could there be a high astonishment factor
>>> associated with this feature?"] and consistency that was meant to
>>> pervade REXX. For example:
>>>
>>> time("H") time("M") time("S")
>>>
>>> all provide counts of the numbers of time-intervals past midnight of a
>>> particular time. So why doesn't time("T") provide a tick-count since
>>> midnight and time("F") provide a microsecond count since midnight?
>> They extend the Time function to make it more robust. If
>> you don't need the additional capability, simply don't use it.
>
> (Why don't you put blank lines into your replies? It makes it hard to
> read.)
>
>
Oops! My bad, sorry.