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?)
10 Comments Comments:
Gregg Irwin
6-Jul-2009 15:17:28 |
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. | meijeru
6-Jul-2009 15:47:29 |
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...) | Sunanda
6-Jul-2009 17:04:11 |
Nice the way the pickable elements have been extended:
t: now
for n 1 9 1 [
print pick t n
]
| Brian Hawley
6-Jul-2009 17:47:19 |
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. | Jerry Tsai
6-Jul-2009 20:46:07 |
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. | meijeru
7-Jul-2009 6:03:29 |
(at)Sunanda: what do you say the 9th element is meant to be?
I get none when I pick it. | Sunanda
7-Jul-2009 12:10:30 |
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. | -pekr-
7-Jul-2009 15:20:42 |
Jerry, sadly for you, the next REBOL DevCon is - GMT+1 - Prague :-) | Rebolek
14-Jul-2009 4:04:10 |
Thanks for the 0:15 resolution for time zones, that's great! | alanwall
24-Jul-2009 3:55:45 |
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.
|
