Comments on: 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?)
Excellent news! While the 0:15 resolution on zones isn't needed by everyone, it will be most welcome in global apps, and is one less thing to work around.
P.S. It's a pain to have to enter the captcha twice.
the total number of time-zones representable this way is 121 (2 * 4 * 15 + 1); with 8 bits you would have room for twice as many; what is the 8th bit used for? (just curious...)|
Nice the way the pickable elements have been extended:
for n 1 9 1 [
print pick t n
Note: The new range of zones in date/time syntax is -15:45 to +15:45, in 15 minute increments. MAKE date! or time! also accepts -16:00 or +16:00, which it always treats as -16:00. MAKE date! or time! also does modulo-16:00 arithmetic on the zone. So MAKE has a couple of extra features, as usual.|
No, no, no, no ... (sobbing). The timezone of the location where we are holding the next REBOL DevCon should be +8:00.
BTW, I am trying to introduce Alipay.com (the company I am working for) to the REBOL programming language.
(at)Sunanda: what do you say the 9th element is meant to be?
I get none when I pick it.|
I did 9 to see if 8 was the end. It seems so....Unless there is a hidden track much further along :-)
In R2, the highest is 5, so the extra 3 are R3 bonuses.
Jerry, sadly for you, the next REBOL DevCon is - GMT+1 - Prague :-)|
Thanks for the 0:15 resolution for time zones, that's great!|
I have not tried a test but will it work with DST=day light
saving time ?|
Post a Comment:
You can post a comment here. Keep it on-topic.