Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

Time and again: a wish-list

 [1/1] from: alex::pini::mclink::it at: 12-Aug-2000 17:42

>- Open Your Mind -<
I've recently banged my head on time-related limitations. I'll spare you the whole mental path I followed. The conclusion is that it would be much more *comfortable* (VIK, Very Important Keyword) and it would add a little to REBOL's *prestige* ("Oh, your puny language doesn't allow you to...") to have some things embedded in the REBOL executable rather than having each individual programmer find their own solution to the problem (reinvention of the wheel, etc.). ---------- The ability to ask for "now/time/minute", for example, instead of having to ask for "t: now/time t/minute" or for "d: now d/time/minute". ---------- The "nanosecond" refinement: "now/nanosecond", already requested by other people. ---------- The "accurate" or "precise" (or similar) refinement (even if the system clock can't be *so* accurate, see AREXX):
>> now/precise
== 12-Aug-2000/15:37:11.181731917+1:00
>> now/time/precise
== 15:37:11.181731917 ---------- The "to-seconds" function (how much is a mezzanine slower than a native?).
>> t
== 16:49:28.123456789
>> t/hour * 3600 + t/minute * 60 + t/second
== 3458968.1234568 ... and the like for dates, yielding (YIKES!) the number of seconds since day 1!!! :-) Or since a given reference date, using a refinement: "to-seconds/since t 1-1-1971/07:55". With automatic leap-second compensation. Of course, using a future date, it has to yield the number of seconds you have to wait (have you bought the flowers? :-). ---------- The "to-days" function. See above, for timeless dates (I don't *always* need maximum accuracy :-). ---------- Having "to-date" accept integers (since day 1 or a reference date, with automatic Gregorian compensation).
>> where's-the-moon?: 1-1-0001 + 730009
== 13-Sep-1999 ---------- Improved time-zone management, including (automatic?) conversion to/from other time-zones (for example, my web-server is in the U.S.A., but most of the users will be in Italy, and all the displayed and e-mailed times and time-zones should be converted); accepting (but not yielding!) symbolic time-zones like CET, PST, PDT, GMT, ITMT (in the meantime :-). ---------- Arithmetics on full date/time pairs, including time-zone compensation.
>> d0
== 12-Aug-2000/16:16:52+1:00
>> d1
== 12-Aug-2000/16:17+1:00
>> d1 - d0
== 0 Why? There's an eight-second difference.
>> d2
== 12-Aug-2000/16:17+2:00
>> d2 - d1
== 0 Why? There's a one-hour difference.
>> d3
== 16-Aug-2000/16:17+2:00
>> d3 - d0
== 4 Why? The difference here is 4 days, one hour and eight seconds (notice an integer coming out of two full dates). I know the result I'm talking about is a relative date/time coming out of two absolute dates, so maybe it's time for a timezoneless relative date/time datatype, something yielding 0/00:00:08, 0/01:00:00, 4/01:00:08 and possibly 12345/12:34:56.123456789 using the "accurate" refinement. ---------- Finally, I'd like to know why the hell all my e-mails to REBOL feedback bounce back! Alessandro Pini ([alex--pini--mclink--it]) Well... What *are* our chances? Over 50%? "32. Point 7." "I'm sorry I asked!" (Garak & Bashir)