<br><br><div><span class="gmail_quote">On 21/11/2007, <b class="gmail_sendername">Scott Wheeler</b> <<a href="mailto:wheeler@kde.org">wheeler@kde.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>This is another one of those where the devil is in the details. Just<br>having a function to pass through the value to C's time() would be<br>trivial. (About 10 lines of code added to ulib_std.cpp) However, with
<br>support for time comes time zones, daylight savings time, conversions<br>between local time and universal time, addition and subtraction of time,<br>etc. And then it's a big pain in the ass.</blockquote><div><br>
<br>Really? this might sound naive but I feel it's up to the OS to keep track of those. The little clocks at the bottom of the desktop can have the time, why not some arbitrary program?<br><br>Actually, I just remembered that our auto-rec example uses some sort of trick to time-stamp saved files to quote a filename I just saw;
<br><br>chuck-session(Mon Jun 25 00h42m33 2007).wav<br></div><br>This (in a format readable without lots of string management) would be fine with me, if I go across time-zone I have to re-set the system clock anyway.<br><br>
I once tried to exploit the trick ChucK uses there, I remember now, to tell the time but never succeeded, it seems hard-wired into the file saving Ugen. You are right that something like that wouldn't be enough to -say- manage nuclear reactors across continents but it would be enough for cheep&cheerful bleeps & booms for fun & profit and that would be enough for me, for now at least ;¬).
<br><br>Yours,<br>Kas.<br></div>