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 fixedpoint 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 base10 (not base2) 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 highprecision 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 1Jan2010/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 6Jul2009 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 6Jul2009 15:47:29 
the total number of timezones 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 6Jul2009 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 6Jul2009 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 modulo16:00 arithmetic on the zone. So MAKE has a couple of extra features, as usual.  Jerry Tsai 6Jul2009 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 7Jul2009 6:03:29 
(at)Sunanda: what do you say the 9th element is meant to be?
I get none when I pick it.  Sunanda 7Jul2009 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 7Jul2009 15:20:42 
Jerry, sadly for you, the next REBOL DevCon is  GMT+1  Prague :)  Rebolek 14Jul2009 4:04:10 
Thanks for the 0:15 resolution for time zones, that's great!  alanwall 24Jul2009 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 ontopic.
