About TIME Changes

In A67 major changes have been made to the TIME datatype. These changes were necessary due to the types of bugs we were seeing in time. The origin of these was the old R2 time implementation which was imported into R3 rather than being rewritten.

the overall goal of this effort was to make the time math (and therefore dates) more robust and reliable. We all need to depend on it.

Essentially, TIME is a 64 bit fixed-point number. In R2, this was split between 32 bits for seconds and 32 bits for nanosecond. It was designed that way because 64 bit math was not standard on all target platforms (at that time), and the nanosecond field was thought to be rarely used (so why compute it each time.)

Now, in R3 A67, TIME is a 64 bit integer representing nanoseconds. This simplifies all internal math operations because they can deal with a single integer, rather than two separate values that have a base-10 (not base-2) relationship.

It should be noted that nanosecond truncation errors will occur due to the fixed point method. For most time values, this is not a problem because they don't need nanosecond precision. (And there aren't many guarantees when it comes to nanosecond timing on PCs, but if you need that level of precision, say for your space telescopes or proton accelerators, use the high-precision math supported in the money datatype.)

Anyway, time! now passes the tests I have here, and it can be released. Please test it carefully because we are aiming for zero errors in it. If you find a problem, contact me.

PS: As part of this change, time zone resolution has been extended to 15 minutes. E.g. this is valid now 1-Jan-2010/10:30+5:45 (Kathmandu, Napal). Zone range is +/- 15:00 by 0:15 increments (so, you can now use REBOL in Tonga. Location of next DevCon?)

10 Comments