Re: [Oorexx-devel] Nano-/Picoseconds, "datergf"-specs and Default Numeric Digits ... (Re: Need a name for a new time option

[Rony G. F. <Ron...@wu...>]

Rick McGuire wrote:
> On 9/8/07, *Rony G. Flatscher* <Ron...@wu...
> <mailto:Ron...@wu...>> wrote:
>
>
>     Rick McGuire wrote:
>>     It's pretty much a given that any value that can be used to
>>     represent the date range supported by ooRexx for computation will
>>     need to use higher than the default digits setting.  For example,
>>     there are 63324720000 seconds in the basedate representing
>>     today's date, which requires numeric digits 11 to calculate.  The
>>     date 12/31/9999 requires 12.  I chose the resolution of
>>     microseconds because that would allow lossless conversion between
>>     any date/time format currently supported by Rexx. 
>     Nanosecond resolutions seem to have become "widely" deployed. E.g.
>     .NET has a resolution of nanoseconds, if I am not mistaken. (So if
>     interacting with .NET in the future with a need of time bits, then
>     nanoseconds would be a requirement.) Also SQL 2008 seems to have
>     nanoseconds resolution in its date/time block. Nanoseconds have
>     become visible in all kind of contexts (e.g. IBM's DB2 UDB logs,
>     cf. <http://www-1.ibm.com/support/docview.wss?uid=swg1IY88524>).
>
>
> .NET has a high performance timer which is just an internal timer.  It
> does not have any means of getting a time stamp value with a
> resolution any greater than hundredths of a second.

Not according to
<http://msdn2.microsoft.com/en-us/library/system.datetime.aspx> and
<http://msdn2.microsoft.com/en-us/library/system.datetime.ticks.aspx>.
The .Net DateTime has a member named "Ticks", which stores the 100ns
Ticks since January 1st, 0001, midnight (00:00 or "12:00AM").

... snip ...

> Absolutely not.  This is a problem that woiuld require a complete
> reworking of the code.  This RFE will not be used as justification for
> opening up that issue.  I'd appreciate it if the RFE discussion was
> contained to the issue we need to reach resolution on, not widened to
> everything in the world.
This is not a thought on "everything in the world", at least it was not
meant as such. While discussing resolution sizes and employing
arithmetics with them, it is also necessary to think about
ramifications, which in this context of Rexx touches the default setting
for Numeric Digits. Hence also thinking about possible resolutions (and
pointing out at other areas where the default setting of 9 digits poses
problems with modern hardware).

However, I do understand from your comment (default setting of 9
hard-coded at present, hence could not be changed easily) that this is
mute at the moment and that therefore you wish to focus on your new
Time-RFE.

---rony