Re: Dates and times again
Dan Sugalski [EMAIL PROTECTED] writes: In an attempt to drain the swamp... So far as I can see, we need, in descending order of importance (and speed) (And if there's stuff missing, add them): 1) A timestamp value 2) A way to chop the timestamp to pieces 3) A way to turn the timestamp into a string 4) A way to turn pieces to a timestamp 5) A way to turn the string into a timestamp All of which is confounded by the joys of timezones and platform limitations. As far as I can tell, the only thing we can absolutely count on are: asctime, ctime, difftime, gmtime, localtime, mktime, strftime Everything gives you a ticks of size ? since ? hook or three. In most places the ticks are less than second. All the stringify and human/planet-izing seems to be library fodder. gettimeofday() is widely available or fakeable. (Tk uses it.) Seems $^T could start based on time(2) and then get deltas using something finer. Perhaps aspire to clock_gettime() and fake that interface where not available? We can't even count on timegm, unfortunately. Neither can we count on getting fractional time. (Or even really count on getting a GMT time that's actually GMT, as far as that goes, but that's user-misconfiguration and there's a limit to what I'm willing to care about) Nor strptime for time parsing, though a case could be made there that we could do our own. (Cases to be made for that should be accompanied by unencumbered source to do the parsing ;) Can't even count on the full range of output when splitting the time up--if you check the CVS logs you'll see I yanked out a few elements because they're not C89 and there wasn't any way to synthesize them easily that I know of. That means we can't convert to TAI, since that needs leap second info we don't have, so base time can't be TAI. From what I can tell from the interfaces and long painful experience we can't convert to and from anything other than the current system timezone. (Maybe. I'm not 100% sure that's reliable either) Right now, you can get a black-box integer timestamp that's fixed to GMT time, and you can disassemble that timestamp into day/month/year pieces. I adjusted the year to be a real year, but I haven't adjusted the month. We can do that, though. We can easily: *) Give a float timestamp *) Adjust the timestamp to various base dates (I've already made my preferences clear :) My general rule-of-thumb for ops is that they must: *) Be something we want to guarantee behaviour on everywhere *) Require C code *) Have a fixed signature Being primitive isn't necessary as such, but doesn't hurt. Having to be required present at all times isn't necessary either, though we should nail down lexical oplibs if we want to start talking about secondary libraries of this stuff. Anyway, given the restrictions on what we have to work with, the first question is: *) Is what we're providing correct *) What *aren't* we providing that we must to allow full and proper date processing in modules without much pain?
Re: Dates and times again
Larry Wall [EMAIL PROTECTED] writes: That would seem like good future proofing. Someday every computer will have decentish subsecond timing. I hope to see it in my lifetime... It isn't having the sub-second time in the computer it is the API to get at it... My guess is that eventually they'll decide to put a moratorium on leap seconds, with the recommendation that the problem be revisited just before 2100, on the assumption that we'll add all of a century's leap seconds at once at the end of each century. That would let civil time drift by at most a minute or two before being hauled back to astronomical time. Given that most people live more than an minute or two from their civil-time meridian who will notice? (Says me about 8 minutes west of GMT.) I'd say what's missing are the error bars. I don't mind if the timestamp comes back integral on machines that can't support subsecond timing, but I darn well better *know* that I can't sleep(.25), or strange things are gonna happen. But you can fake sleep() with select() or whatever.
Re: Dates and times again
Nick Ing-Simmons [EMAIL PROTECTED] wrote: Larry Wall [EMAIL PROTECTED] writes: ..., but I darn well better *know* that I can't sleep(.25), or strange things are gonna happen. But you can fake sleep() with select() or whatever. $ cat sl.pasm sleep 0.1 end $ time parrot sl.pasm real0m0.116s user0m0.010s sys 0m0.000s leo
Re: Dates and Times
On Sat, 6 Mar 2004, Jared Rhine wrote: It'd be great, if possible, to get a statement here from the DateTime group sanctioning one or another particular Parrot clock interfaces as efficient, complete, and preferred. I haven't poked over to see if they are chatting about this Parrot issue. A few of us have already offered opinions... What we would like for DateTime.pm is an epoch that is _absolutely_ fixed across all platforms. perl does not provide this so we are dependent on the behavior of time(), gmtime(), and Time::Local to make up for this. I have already suggested that Parrot include an op that returns TAI but I would happily settle for gettimeofday(2). What ever is decided upon Parrot should commit to making it consistent across _all_ platforms. -J --
Re: Dates and Times
On Tue, 9 Mar 2004, Edward S. Peschko wrote: On Tue, Mar 09, 2004 at 04:21:24PM -0500, Gordon Henriksen wrote: Not an opcode doesn't mean balkanized. There is a parrot/stdlib directory. fair enough, but then where does the distinction lie? Why put gmtime, et al. in opcodes? As well as addmonth? Returning the current time since epoch x should be an opcode as this is a very common and latency sensitive operation. I believe an awful lot of code only wants to determine the elapsed amount of time by subtracting to subsequent timestamps. Date and time manipulation is complicated and belongs at a much higher level. If you are optimising for simplicity and , it surely makes sense to put these in the standard library. Only if it's a _correct_ implementation. There is no reason why DateTime.pm couldn't be ported to Parrot after object support settles down a bit. If you are optimising for speed, then it makes sense to put them in opcodes. Bloating the core doesn't count as an optimization. But I don't see the 'creeping featuritis' that you see. As well as the memory imprint problems that you see. Is parrot going to link with libc? If so, you get a ton of functionality for (almost) free, just by doing an intelligent wrapper around strftime. As well as providing much of your localization support. And you get a natural boundary on what functionality should be put (in the core) versus what should be put in a module. We all know how consistent the nice vendors are with there libc implementations. :) Do we really want to expose the platform specific strftime() extensions? -J --
Re: Dates and Times
On Tue, 9 Mar 2004, Edward S. Peschko wrote: This sort of creeping featuritis is why date formatting and especially parsing do NOT belong as opcodes. It's too big a problem to solve in the I agree. And the more I think about it, the more I think this concern is misplaced. Putting it in an opcode will make it *harder* to do this type of thing, not easier. In perl5 land, backwards - and forwards - compatibility is a big concern. There will be a large tendency to stabilize any implementation that occurs here. So why do you think time manipulation is about the only thing left out of the x86 ISA? :) -J --
Dates and times again
In an attempt to drain the swamp... So far as I can see, we need, in descending order of importance (and speed) (And if there's stuff missing, add them): 1) A timestamp value 2) A way to chop the timestamp to pieces 3) A way to turn the timestamp into a string 4) A way to turn pieces to a timestamp 5) A way to turn the string into a timestamp All of which is confounded by the joys of timezones and platform limitations. As far as I can tell, the only thing we can absolutely count on are: asctime, ctime, difftime, gmtime, localtime, mktime, strftime We can't even count on timegm, unfortunately. Neither can we count on getting fractional time. (Or even really count on getting a GMT time that's actually GMT, as far as that goes, but that's user-misconfiguration and there's a limit to what I'm willing to care about) Nor strptime for time parsing, though a case could be made there that we could do our own. (Cases to be made for that should be accompanied by unencumbered source to do the parsing ;) Can't even count on the full range of output when splitting the time up--if you check the CVS logs you'll see I yanked out a few elements because they're not C89 and there wasn't any way to synthesize them easily that I know of. That means we can't convert to TAI, since that needs leap second info we don't have, so base time can't be TAI. From what I can tell from the interfaces and long painful experience we can't convert to and from anything other than the current system timezone. (Maybe. I'm not 100% sure that's reliable either) Right now, you can get a black-box integer timestamp that's fixed to GMT time, and you can disassemble that timestamp into day/month/year pieces. I adjusted the year to be a real year, but I haven't adjusted the month. We can do that, though. We can easily: *) Give a float timestamp *) Adjust the timestamp to various base dates (I've already made my preferences clear :) My general rule-of-thumb for ops is that they must: *) Be something we want to guarantee behaviour on everywhere *) Require C code *) Have a fixed signature Being primitive isn't necessary as such, but doesn't hurt. Having to be required present at all times isn't necessary either, though we should nail down lexical oplibs if we want to start talking about secondary libraries of this stuff. Anyway, given the restrictions on what we have to work with, the first question is: *) Is what we're providing correct *) What *aren't* we providing that we must to allow full and proper date processing in modules without much pain? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Dates and times again
On Wed, Mar 10, 2004 at 09:59:32AM -0500, Dan Sugalski wrote: : That means we can't convert to TAI, since that needs leap second info : we don't have, so base time can't be TAI. That part is only half true. Or maybe less than half, if UTC decides to cut loose from astronomical time and ends up tracking TAI exactly from now on. But we *do* know the mappings in the past. (Well, for the recent past, anyway. :-) : Right now, you can get a black-box integer timestamp that's fixed to : GMT time, and you can disassemble that timestamp into day/month/year : pieces. I adjusted the year to be a real year, but I haven't adjusted : the month. We can do that, though. We can easily: : : *) Give a float timestamp That would seem like good future proofing. Someday every computer will have decentish subsecond timing. I hope to see it in my lifetime... : *) Adjust the timestamp to various base dates (I've already made my :preferences clear :) 0 on 1/1/2000 works out very well if it turns out we don't do UTC leaps seconds any more. Then TAI and UTC only go nonlinear before 2000, and so far that's in the past, which is generally easier to predict afterwards, given enough historical evidence. And if they do add leaps to UTC in the future, then at least TAI and GMT always march in lockstep, and we'll be no worse off than we are now. :-) It will be very good if the fate of leap seconds is decided well before POSIX has to consider how to store time after that date in 2038. --http://www.ucolick.org/~sla/leapsecs/onlinebib.html My guess is that eventually they'll decide to put a moratorium on leap seconds, with the recommendation that the problem be revisited just before 2100, on the assumption that we'll add all of a century's leap seconds at once at the end of each century. That would let civil time drift by at most a minute or two before being hauled back to astronomical time. More to the point, it would put the problem off till another day (not to mention another generation). So that's my prediction. But then, I'm terrible at time estimation... : *) Is what we're providing correct I'd say what's missing are the error bars. I don't mind if the timestamp comes back integral on machines that can't support subsecond timing, but I darn well better *know* that I can't sleep(.25), or strange things are gonna happen. : *) What *aren't* we providing that we must to allow full and :proper date processing in modules without much pain? Snap-to-grid semantics for when the clock inevitably gets off by a second or two from somebody's idea of the correct time. (But that should be solved in your levels two through five, not in the timestamp.) The basic idea is I can add 86400 seconds to yesterday and I get the same time today, even if there was a leap second. One would have to request such a snap explicitly, I expect, because you'd have to communicate to it that you don't actually care about sub-minute times, or whatever your grid specifies. But that's how graphics programmers solve the mouse jitter problem, and I think we can learn from them. Larry
Re: Dates and Times
Leave parsing and formatting entirely to libraries. Absolutely no need for that in the instruction set. well, I have a bit of a problem with that... As it was pointed out before, people have gone hogwild with the parsing and formatting routines, and its a bloodbath of modules on CPAN with different methods for time parsing. Which is a pity, because an augmented strftime and its reverse would handle most if not all of the parsing needs, ie: strftime( out Sx, in Sy, in Nz ) where Sx is an output date string Sy is a format described by strftime (ex: %y = 2 digit year %Y = 4 digit year,etc) Nz is the number of seconds past a certain epoch (provided by gmclock, time) r_strftime( out Nx, in Sy, in Sz ) where Nx is the number of seconds past a certain epoch Sy is a format for a given date (provided by strftime) Sz is the date to be converted to in seconds Perhaps there could be an extra argument for locales - and maybe the op could be split in two (ie: for (r_)gm_fmtime, (r_)local_fmtime), but for me, in processing time values most of the time you know the format for dates - as long as they are machine generated. If they are not, you can always fall back to the very slow Date::Parse and cousins, or maybe string these ops along in a chain of '||' to query for multiple formats. But how many times are you going to need to parse formats like '3 weeks from next Wednesday?'. Whether or not this is a low-level module or an op is debatable, but standardizing on one type of formatting dates at the lowest possible level would make perl6 much much cleaner. And right now, things are way too slow - any low level module doing this would IMO need to do it in C anyways to get the fastest possible speed, which seems to argue for them being ops. Ed
RE: Dates and Times
Jared Rhine wrote: Gordon Henriksen wrote: gmclock(out Nx) UTC clock in seconds since hrs Jan 1, 2000, ignoring leap seconds. tolocal out Nx, out Iy, in Nz x is set to z converted to the local time zone. y - 1 if Daylight Savings Time was in effect at z; y - 0 otherwise. splittime Px, Nx Splits date up like Perl 5 gmtime. (But without annoying y -= 1900 and m -= 1?) add_months(out Nx, in Ny, in Nz) Sets x to y + z months. This proposal was perhaps taken offline by the core team, but to avoid a Warnock, I'll pipe up and say I like this proposal as a core instruction set. Thanks for the anti-Warnock. It'd be nice if the first item, gmclock wasn't defined in terms of UTC. Regardless of the future fate of UTC leap seconds, any UTC-based clock would need to account for leap seconds going back, right? So it seems that GMT should be preferred in the core, with any UTC calculations being performed at the language or module level. So, gmclock seems the right opcode (not utcclock), making the definition GMT clock in seconds since hrs Jan 1, 2000. Fair enough. I wasn't trying to load terms for once. In point of fact, this set of opcodes is very much agnostic to whether or not leap seconds are used. The reason that add_months belongs as an opcode is because there's been no decision made re leap seconds, and in fact some anti-decisions have been proposed. Without some way to manipulate dates in accordance with the actual rules that get used (which might be platform dependent at this point), a portable program can't be written. Were this decision made solidly, then all of the ops except gmclock and possibly tolocal would be better written as library code. Were leap seconds to fall in the middle of a month, then we would need to have an add_days op. Since that's not the case, the assumption that a day is 86400 seconds long is safe so long as you avoid adding enough days to cross a year boundary. Meanwhile, add_months encapsulates the leap-second worries AND lets IMC code conveniently manipulate dates without days-per-month tables and is-it-a-leap-year algorithms (which are required to convert add_months to add_days). Daylight savings time calculation seems appropriate to stay in the core, but perhaps additional opcodes are need to set the clock's understanding of the time zone used for DST calculations? Indeed; the local time zone is pretty narrow-minded and backwards- thinking. The problem is balancing weight with efficiency, and time zone databases are pretty heavy critters, which make me think get thee OUT of the core!... # years Nz = Py[5] Nz = Nz - 2000# epoch based at year 2000 Nz = Nz * 12 # = months per year inappropriate sarcasmI look forward to the exciting advancement of changing from subtracting 1900 from all my dates to subtracting 2000 or dealing with negative numbers; that'll change everything and really advance the state of the art./sarcasm What you're complaining about is the elements of Perl's gmtime/localtime arrays. Actually, I suggested removing that quirk from splittime: splittime Px, Nx Splits date up like Perl 5 gmtime. (But without annoying y -= 1900 and m -= 1?) ^^^ ^^ The Nz - 2000 is conversion *to* the epoch, not reinterpreting the value in the array. Unless you think storing dates and times as the number of seconds since Jan 1 is a good idea, perhaps. :) I'd used Jan 1 2000 as an epoch since Larry suggested that's what he was planning for Perl 6 to use. -- Gordon Henriksen IT Manager ICLUBcentral Inc. [EMAIL PROTECTED]
RE: Dates and Times
Edward S. Peschko wrote: Gordon Henriksen wrote: Leave parsing and formatting entirely to libraries. Absolutely no need for that in the instruction set. well, I have a bit of a problem with that... As it was pointed out before, people have gone hogwild with the parsing and formatting routines, and its a bloodbath of modules on CPAN with different methods for time parsing. Not an opcode doesn't mean balkanized. There is a parrot/stdlib directory. Perhaps there could be an extra argument for locales - and maybe the op could be split in two (ie: for (r_)gm_fmtime, (r_)local_fmtime), but for me, in processing time values most of the time you know the format for dates - as long as they are machine generated. If they are not, you can always fall back to the very slow Date::Parse and cousins, or maybe string these ops along in a chain of '||' to query for multiple formats. But how many times are you going to need to parse formats like '3 weeks from next Wednesday?'. Uh. Yeah. This sort of creeping featuritis is why date formatting and especially parsing do NOT belong as opcodes. It's too big a problem to solve in the core, and regardless of how rich the interface is, it'll never be quite rich enough to satisfy everyone. Someone depends on formats like 3 weeks from next Wednesday on a regular basis. You might not need to format dates from the Chinese lunar calendar, but you can bet that it's vital to someone. Eras? Well, sure. Fuzzy date parsing? (Guessing.) Oh, baby. Global time zone database? Bring it on. A kl-hw (Klingon Homeworld) locale? But of course! There'll always be pressure to further enhance the feature, increasing parrot's *core* memory footprint. You can't skip loading the implem- entation of core parrot ops like you can avoid DateTime.pm. So keep it to (un)loadable user code, and provide a class that solves 90% of the problem in the stdlib. Also, trying to nail down a rich interface before seeing what Larry has in mind for Perl 6 date handling is roughly a waste of time -- Gordon Henriksen IT Manager ICLUBcentral Inc. [EMAIL PROTECTED]
Re: Dates and Times
On Tue, Mar 09, 2004 at 04:21:24PM -0500, Gordon Henriksen wrote: Edward S. Peschko wrote: Gordon Henriksen wrote: Leave parsing and formatting entirely to libraries. Absolutely no need for that in the instruction set. well, I have a bit of a problem with that... As it was pointed out before, people have gone hogwild with the parsing and formatting routines, and its a bloodbath of modules on CPAN with different methods for time parsing. Not an opcode doesn't mean balkanized. There is a parrot/stdlib directory. fair enough, but then where does the distinction lie? Why put gmtime, et al. in opcodes? As well as addmonth? If you are optimising for simplicity and , it surely makes sense to put these in the standard library. If you are optimising for speed, then it makes sense to put them in opcodes. It all comes down to how fast one is versus the other. If everything is going to be built in the standard library based off of bytecode then there will be a performance hit. How severe, I don't know, but definitely a performance hit. And given the prevalence of string and date manipulation in every day tasks, I would suggest not having that performance hit. But how many times are you going to need to parse formats like '3 weeks from next Wednesday?'. Uh. Yeah. This sort of creeping featuritis is why date formatting and especially parsing do NOT belong as opcodes. It's too big a problem to solve in the But I don't see the 'creeping featuritis' that you see. As well as the memory imprint problems that you see. Is parrot going to link with libc? If so, you get a ton of functionality for (almost) free, just by doing an intelligent wrapper around strftime. As well as providing much of your localization support. And you get a natural boundary on what functionality should be put (in the core) versus what should be put in a module. And any scheme that Larry would come up with would be implemented in terms of what would be in parrot. The problem would then come down to filling in deficiencies of individual C89 implementations (which hopefully will lessen as time goes on), making an intelligent interface into strftime, and doing a reverse lookup. How I'd love to be able to do in my code: my @date_formats = map( strftime( %a %b %e %T %Z %Y, r_strftime( %b %d %Y, $_)) , @ls_formatted_dates ); where r_strftime converted back to floating point seconds and then strftime reconverted back into @date_formats.. or my $secs = gmclock(); my @oracle_dates = map( strftime(%d-%b-%Y, addmonths( $secs, $_)), (1..10)) making 10 dates each spaced a month apart and formatting them for inclusion into oracle. Given the prevalence in which this is done, I'd want to do it *fast*. As I see it, with an opcode this will be as fast as possible, approaching C speed. So - if you can guarantee that there isn't going to be a lot of overhead by putting it in stdlib, then sure by all means it should be put there. Someone depends on formats like 3 weeks from next Wednesday on a regular basis. You might not need to format dates from the Chinese lunar calendar but you can bet that it's vital to someone. Look at strftime(3C) some time. I'd say that the problem has been to a large extent solved. Yes, it doesn't handle TAI or other epochs, which could be handled by an offset, and yes, there aren't certain I would think that most of this can parsing? (Guessing.) Oh, baby. Global time zone database? Bring it on. A kl-hw (Klingon Homeworld) locale? But of course! Most of the above is already there (well, maybe not klingon). Do you want to reinvent everything? What's not there could be implemented in terms of a wrapper around the opcode. Or augmented inside the opcode. It would be a judgement call as to which though. There'll always be pressure to further enhance the feature, increasing parrot's *core* memory footprint. You can't skip loading the implem- entation of core parrot ops like you can avoid DateTime.pm. Resist the temptation then. Like I said, strftime provides quite a lot. So keep it to (un)loadable user code, and provide a class that solves 90% of the problem in the stdlib. like I said, if there isn't a performance penalty for this, then go ahead. If there is a substantial performance penalty for every time I manipulate a date, you could easily make the argument 'so keep the core ops relatively small, which solve 90% of the problem, and put the rest into a wrapper inside stdlib.' Also, trying to nail down a rich interface before seeing what Larry has in mind for Perl 6 date handling is roughly a waste of time well, no, I don't think so.. At least if I was developing perl6 I'd want some input on it. The RFCs after all are 3 years old, and at some point there is going to have to be a merging between perl6-internals and perl6-language.. Ed
Re: Dates and Times
At 03:52 PM 3/9/2004 -0800, Edward S. Peschko wrote: On Tue, Mar 09, 2004 at 04:21:24PM -0500, Gordon Henriksen wrote: Not an opcode doesn't mean balkanized. There is a parrot/stdlib directory. fair enough, but then where does the distinction lie? Why put gmtime, et al. in opcodes? As well as addmonth? If you are optimising for simplicity and , it surely makes sense to put these in the standard library. If you are optimising for speed, then it makes sense to put them in opcodes. I don't think optimising for X is the reason. Parrot should have concise, necessary, complete opcode primitives upon which anything else can be built. Date parsing can be done all with opcodes, but please not inside opcodes. If we cannot provide a decently performing VM that makes people want to write stuff in bytecode (or compiled to bytecode) we have failed anyway. It all comes down to how fast one is versus the other. If everything is going to be built in the standard library based off of bytecode then there will be a performance hit. How severe, I don't know, but definitely a performance hit. This is subjective reasoning, though. If we want to talk performance hits, we should know where we stand. When bytecode isn't full of PMC thrashing, and actually uses the low level Ix and Sx registers where possible, the JIT works extremely well and the performance beats Perl5 by several orders of magnitude in many cases. Hopefully the hints in Perl6 will help us write better libraries, but some of it may have to be written in IMC or slightly higher level language (on the equivalent of C, compilable to bytecode). But how many times are you going to need to parse formats like '3 weeks from next Wednesday?'. This sort of creeping featuritis is why date formatting and especially parsing do NOT belong as opcodes. It's too big a problem to solve in the I agree. But I don't see the 'creeping featuritis' that you see. As well as the memory imprint problems that you see. Is parrot going to link with libc? Yes, Parrot will link with libc. Regardless of what we implement as opcodes, there will never be a single solution that fits all, and it will never, ever end. Just look at Linux. -Melvin
Re: Dates and Times
I don't think optimising for X is the reason. Parrot should have concise, necessary, complete opcode primitives upon which anything else can be built. how about opcode formatting primitives? That is what I would argue strftime and relatives are... generic low-level ways of turning strings into dates into numbers (seconds) and vice-versa. That they are part of a standard low-level library (libc) that is widely available and can be described in terms of parrot primitives (strings, numbers), and the fact that this low-level library is well known, tested and supported on various platforms just seems to me to be a tremendous timesaver. Date parsing can be done all with opcodes, but please not inside opcodes. If we cannot provide a decently performing VM that makes people want to write stuff in bytecode (or compiled to bytecode) we have failed anyway. I agree that facilitating easy bytecode writing is really important - but reimplementing a pretty standard wheel and having that pretty standard wheel be slower than what is available doesn't seem to be useful to me. Taking the standard wheel and augmenting it seems more useful IMO. This is subjective reasoning, though. If we want to talk performance hits, we should know where we stand. When bytecode isn't full of PMC thrashing, and actually uses the low level Ix and Sx registers where possible, the JIT works extremely well and the performance beats Perl5 by several orders of magnitude in many cases. Hopefully the hints in Perl6 will help us write better libraries, but some of it may have to be written in IMC or slightly higher level language (on the equivalent of C, compilable to bytecode). I tell you what - why don't base your decision on an empirical test. I'll write a c program around strftime that does a given set of formatting dates and times, as well as the reverse translation, and we can benchmark that program versus the bytecode that parrot offers in a stdlib on a list of tasks. After some optimising iterations, we'll compare the results. And depending on the performance difference, you can decide whether or not its worth the effort to put these primitives in the core. This sort of creeping featuritis is why date formatting and especially parsing do NOT belong as opcodes. It's too big a problem to solve in the I agree. And the more I think about it, the more I think this concern is misplaced. Putting it in an opcode will make it *harder* to do this type of thing, not easier. In perl5 land, backwards - and forwards - compatibility is a big concern. There will be a large tendency to stabilize any implementation that occurs here. Ed
Re: Dates and Times
Edward, Want to call strptime? Use NCI. No need for anything new in the core. That's WHY it's the CORE. Gordon Henriksen [EMAIL PROTECTED]
Re: Dates and Times
On Tue, Mar 09, 2004 at 09:53:47PM -0500, Gordon Henriksen wrote: Edward, Want to call strptime? Use NCI. No need for anything new in the core. That's WHY it's the CORE. I think there is a misunderstanding here. I don't think that strftime by itself in the core - which probably has system dependencies and inconsistancies - is a good idea. Or for that matter, calling strftime directly is a good idea. What I think is a good idea is a light wrapper around strftime, one that irons out the inconsistencies inherent in different platforms, and adds a reverse function which takes a format and turns it back into a number of seconds. I don't know of any other function that does this, and I can tell you as a heavy user of perl in a production environment having a lightweight, fast, function that does this is very very useful. The faster the better. Anyways - like I said, I don't have anything against it being in a standard library, as long as it doesn't have too much overhead and is reasonably efficient. But I'm doubtful that this can really be done vs having it as an op - hence the idea of an extensive benchmark. Ed ( ps - I looked for a 'stdlib' directory in parrot-0.1.0.. is it not there? Are stdlibs going to be shared between languages that host parrot? )
Re: Dates and Times
Edward S. Peschko wrote: On Tue, Mar 09, 2004 at 09:53:47PM -0500, Gordon Henriksen wrote: Edward, Want to call strptime? Use NCI. No need for anything new in the core. That's WHY it's the CORE. I think there is a misunderstanding here. I don't think that strftime by itself in the core - which probably has system dependencies and inconsistancies - is a good idea. Or for that matter, calling strftime directly is a good idea. ... But I'm doubtful that this can really be done vs having it as an op - hence the idea of an extensive benchmark. On a platform with a halfway decent JIT, a pure-PASM implementation could be as fast as an op-based one, given liberal use of the non-PMC registers. Maybe faster--no need to transcode to ASCII, extract a C string, or hack around platform X's quirks. And I'd imagine that the Parrot standard library would be written to be as fast as possible. Besides, how fast does your date handling really need to be? I mean, *really*? Are you formatting eleventy billion dates in a tight loop or something? -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia. [And once again, I show my incompetence with Thunderbird...]
Re: Dates and Times
Hi Brent, Welcome back to p6i. ;) At 08:12 PM 3/9/2004 -0800, Brent \Dax\ Royal-Gordon wrote: On a platform with a halfway decent JIT, a pure-PASM implementation could be as fast as an op-based one, given liberal use of the non-PMC Agree. Besides, how fast does your date handling really need to be? I mean, *really*? Are you formatting eleventy billion dates in a tight loop or something? I actually have Perl programs that parse many many millions of billing records per day (with 2 dates per record) for certain wireless companies. Sometimes, if the customer wants to do an audit, we have to process over a month's worth, so we are bound by the actual execution time of the Perl script and the access time of a Sleepycat (Berkeley DB) database. The Perl programs must be able to scale with call/message volume, and right now the only thing we can do to improve it is put faster processors on it. (We have 8-way boxes with 64GB RAM, so 4GB hashes work just fine, but 1.5 hrs per day is still very finite when you have to baby sit scripts for a week to give customers the answers they want to know). Granted, I could rewrite this stuff in C, but we typically modify these things on very short notice and Perl gives us the flexibility to react quickly. So, when we are discussing dates, I am one very interested party. -Melvin PS: Sorry I'm so vague about the numbers. The customers are very sensitive about those numbers and I could get in trouble, but lets say they are in the billions for a rather small time sample.
Re: Dates and Times
On a platform with a halfway decent JIT, a pure-PASM implementation could be as fast as an op-based one, given liberal use of the non-PMC registers. Maybe faster--no need to transcode to ASCII, extract a C string, or hack around platform X's quirks. And I'd imagine that the Parrot standard library would be written to be as fast as possible. ok, well cool. We'll see then. Besides, how fast does your date handling really need to be? I mean, *really*? Are you formatting eleventy billion dates in a tight loop or something? yes. Its a major issue/pain in database conversions, and in funnelling data from system to system - in my case, approximately 4 date conversions for each of 2.5 billion rows on different systems, some of them live production. Dates converted from one system standard oracle format to another oracle format. From mysql to db2. db2 to oracle. Date comparisons between different formats. (and yes, I have rolled 'my own' wrapper for handling this stuff. I use it both from perl and generated c to do the conversions. However, I'm sick of rolling my own stuff to 'supplement' what IMO should be native to perl itself.) In any case, like I said, I don't have any problem with standard libraries handling this stuff; as long as whatever library is: a) reasonably fast - ie: within 20% of C b) just as robust as the standard system stuff c) has a reverse formatting function, going back to seconds from dates. d) is standard - handles 95% of necessary date manipulations e) has a tight memory footprint. I think its a waste to reimplement everything though. There is a LOT THERE in libc which could be leveraged. And it definitely would be a good idea for parrot to make dates almost as low level an item as strings,numbers, etc - ie: native datatypes or close to native. A formatting op which tied numbers to strings would do that quite nicely. Ed
Re: Dates and Times
Sometimes, if the customer wants to do an audit, we have to process over a month's worth, so we are bound by the actual execution time of the Perl script and the access time of a Sleepycat (Berkeley DB) database. The Perl programs must be able to scale with call/message volume, and right now the only thing we can do to improve it is put faster processors on it. (We have 8-way boxes with 64GB RAM, so 4GB hashes work just fine, but 1.5 hrs per day is still very finite when you have to baby sit scripts for a week to give customers the answers they want to know). Granted, I could rewrite this stuff in C, but we typically modify these things on very short notice and Perl gives us the flexibility to react quickly. well you could opt for generated C (which is what I do). I generate function calls based on the content of the sql that is to be executed (ie: a md5 hash-like thingy) and bound back to flat files and/or perl data structures. Its a pain in the , but it works, and we are IO bound rather than processor bound on a system with *very* high IO throughput. We also generate the C from perl, of course. Anyways, I'd much rather be able to have perl be able to handle everything, for the reasons you mentioned. Its just too bad that its too slow for the task at hand, given that the system that we were using. Hence the post. So, when we are discussing dates, I am one very interested party. -Melvin PS: Sorry I'm so vague about the numbers. The customers are very sensitive about those numbers and I could get in trouble, but lets say they are in the billions for a rather small time sample. (oops. didn't think of that one. fortunately, I was thinking about it some more, and my estimates I gave in my last email weren't completely accurate.. ;-)) Ed
Dates and Times
[Gordon == [EMAIL PROTECTED] on Wed, 3 Mar 2004 16:48:45 -0500] Gordon gmclock(out Nx) Gordon UTC clock in seconds since hrs Jan 1, 2000, Gordon ignoring leap seconds. Gordon tolocal out Nx, out Iy, in Nz Gordon x is set to z converted to the local time zone. y - 1 Gordon if Daylight Savings Time was in effect at z; y - 0 Gordon otherwise. Gordon splittime Px, Nx Gordon Splits date up like Perl 5 gmtime. (But without Gordon annoying y -= 1900 and m -= 1?) Gordon add_months(out Nx, in Ny, in Nz) Gordon Sets x to y + z months. This proposal was perhaps taken offline by the core team, but to avoid a Warnock, I'll pipe up and say I like this proposal as a core instruction set. It'd be nice if the first item, gmclock wasn't defined in terms of UTC. Regardless of the future fate of UTC leap seconds, any UTC-based clock would need to account for leap seconds going back, right? So it seems that GMT should be preferred in the core, with any UTC calculations being performed at the language or module level. So, gmclock seems the right opcode (not utcclock), making the definition GMT clock in seconds since hrs Jan 1, 2000. Daylight savings time calculation seems appropriate to stay in the core, but perhaps additional opcodes are need to set the clock's understanding of the time zone used for DST calculations? Gordon# years GordonNz = Py[5] GordonNz = Nz - 2000# epoch based at year 2000 GordonNz = Nz * 12 # = months per year inappropriate sarcasmI look forward to the exciting advancement of changing from subtracting 1900 from all my dates to subtracting 2000 or dealing with negative numbers; that'll change everything and really advance the state of the art./sarcasm Of course, as Gordon suggests, what I'll actually be doing is relying on some Perl 6 module to give me a nice (non-negative date) object interface. The Parrot instruction should probably be optimized for speed. Formatting can always be kludged together at the language level, but a module will need solid support from Parrot for good duration calculations. Gordon's proposal is tuned for duration calculations, which is ideal. It'd be great, if possible, to get a statement here from the DateTime group sanctioning one or another particular Parrot clock interfaces as efficient, complete, and preferred. I haven't poked over to see if they are chatting about this Parrot issue. -- [EMAIL PROTECTED] A black hole is where God is dividing by zero. -- attributed to Roger Smith
Re: Dates and Times
At 12:55 PM -0800 3/4/04, Robert Spier wrote: I agree. That's why I'd like to see TAI be the default seconds since some epoch. It seems like we want the default to be the simplest and fastest one we can support. Exactly. Which is the count that the system C RTL returns when you ask it, normally claimed to be GMT or something very much like it. If the local system returns localtime, I can see adjusting to GMT or UTC, or whatever, as that ought to be a trivial transform. Past that libraries can deal with it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Dates and Times
On 3/4/04 5:09 PM, Dan Sugalski wrote: If the local system returns localtime, I can see adjusting to GMT or UTC, or whatever, as that ought to be a trivial transform. Er, I'm not so sure about that. That means you'd have to be 100% sure that you can determine the local timezone without any ambiguity. That has not proven to be the case if the DateTime.pm project is any indication... -John
Re: Dates and Times
Interesting -- so the planet's finally gotten its act together and settled on a rotational speed, huh? Cool. :) Nobody said anything about a planet. A clock should tell you how much time has gone by. If I get a time, sleep(1), and get another time, time 2 should be about time1 + 1 second, regardless of leap seconds, what planet I'm on, etc. Translating a timestamp into a date is a separate issue from keeping track of time itself, and should be handled separately. __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com
Re: Dates and Times
Interesting -- so the planet's finally gotten its act together and settled on a rotational speed, huh? Cool. :) Nobody said anything about a planet. Actually, they did. UTC (which was the original reference) is defined such that noon is within .9 seconds of the sun being as directly overhead as it can be, and is thus directly tied to the behaviour of the planet. My point remains. Don't use UTC, then :) That's why we want to ignore leap seconds. __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com
Re: Dates and Times
On Thu, Mar 04, 2004 at 09:12:47AM -0500, Dan Sugalski wrote: : At 7:30 PM -0800 3/3/04, TOGoS wrote: : Interesting -- so the planet's finally gotten : its act together and settled on a rotational : speed, huh? Cool. :) : : Nobody said anything about a planet. : : Actually, they did. UTC (which was the original reference) is defined : such that noon is within .9 seconds of the sun being as directly : overhead as it can be, and is thus directly tied to the behaviour of : the planet. The basic problem is that there are times you need to know exactly how many seconds have passed between two timestamps, and times you need to know exactly how many days have passed between two timestamps, and the two are in conflict. However, I think the more basic problem of the two is the first one. If you ignore that problem, you get all sorts of breakage down in random routines that you don't want breakage in, and this will only get worse as computers get faster, and try to syncronize more low level things. In contrast, the other problem tends to manifest in user interfaces, where it can typically be solved by some snap-to-grid semantics at the minute, hour, and day boundaries, at least until the second timer and the Earth drift apart by 30 seconds or so. Which will take a while. And anyone who needs greater UTC accuracy than that should probably be tracking TAI-UTF offsets anyway, or have some other way of resyncing their clock at least semiyearly. So anyway, I don't care whether Parrot builds in support for complicated time systems like UTC. (Well, I do care some--it should probably be a library in any event.) But I do care that Ctime - $^T be accurate. (In fact, I'd like $^T to change to a floater too, on systems that can support it. It's way past time for hi-res timing to be the default, I think.) Larry
Re: Dates and Times
On Thu, 4 Mar 2004, TOGoS wrote: Actually, they did. UTC (which was the original reference) is defined such that noon is within .9 seconds of the sun being as directly overhead as it can be, and is thus directly tied to the behaviour of the planet. UTC may stop tracking UT1 and stop having [new] leap-seconds. Even if this happens we'll still have to take leap-seconds into account for dates prior to 1999. My point remains. Don't use UTC, then :) That's why we want to ignore leap seconds. I agree. That's why I'd like to see TAI be the default seconds since some epoch. -J --
Re: Dates and Times
I agree. That's why I'd like to see TAI be the default seconds since some epoch. It seems like we want the default to be the simplest and fastest one we can support. If someone wants something different, they can do the moral equivalent of: use Time::TAI; or use Time::UTC; or use Time::MacEpoch; -R
Dates and Times
Yep, time to dive into yet *another* swamp. (Isn't this fun?) Right now we've got the capability of getting the current time in epoch seconds with the time op. This is good. However there's the issue of actually *doing* something with it. I'm torn here as to what to do. On the one hand, it's supremely tempting to punt and not have parrot do a darned thing with the time and leave it to library code to handle it. On the other, CPAN is littered with the carcasses of time and date modules. On the third hand, at least some of the date handling stuff is provided by the underlying C runtime library (there's a lot of interesting stuff in the C89 spec) so it seems silly to reimplement something we're guaranteed to have around anyway. What I'm thinking we may want to do is provide a minimal interface--turn the time integer into a string rep or split out into an array, something like: localtime Sx, Iy gmtime Sx, Iy Returns a formatted string for either localtime or gmt in X, with the value in Y being the return from the time op, and: localtime Px, Iy gmtime Px, Iy returning an array of sec/min/hour/day/month/year/weekday/yearday/isDST?/TZ/secsfromUTC in X from the time int in Y. Uear, in this case, being the actual real year--none of this year-1900 nonsense And yeah, this is a simple wrapper around the C RTL routines. FWIW, if we start getting into the What should our base time for the epoch be arguments, I'll warn you that the answer if I have to make one is probably Nov 17, 1858 at midnight, give or take a bad memory, and our time value'll be a 64-bit integer. So think carefully before you go there. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Dates and Times
At 11:37 AM 3/3/2004 -0500, Dan Sugalski wrote: I'm torn here as to what to do. On the one hand, it's supremely tempting to punt and not have parrot do a darned thing with the time and leave it to library code to handle it. On the other, CPAN is littered with the carcasses of time and date modules. On the third hand, at least some of the date handling stuff is provided by the underlying C runtime library (there's a lot of interesting stuff in the C89 spec) so it seems silly to reimplement something we're guaranteed to have around anyway. What I'm thinking we may want to do is provide a minimal interface--turn the time integer into a string rep or split out into an array, something like: Simple primitives are good. My stuff dealing with dates is usually hand written based on top of the localtime and gmtime calls in the standard Time:: module bundled with Perl anyway. Anything fancier requiring a CPAN download rarely gets used on production boxes because a lot of administrators don't mind installing a pre-built Perl package, but they shy away from downloading and compiling a ton of add-on modules (hey, they can't all be Perl-trained). I know I've been on this soapbox in the past but... I hope, with Parrot, people will get away from a common practice of writing Perl modules in C with a binary interface. Unless the module HAS to be in C for API interface (complex math computations or performance sensitive stuff like encryption and compression where 10% matters), I prefer a pure bytecode implementation for ease of deployment. Some people write both pure Perl and C implementations of modules; to get around that, I hope we can provide a low level, optimizable system programming language for Parrot (or put enough hints in Perl6) so people can write fast implementations without requiring a real C compiler. -Melvin
Re: Dates and Times
What I'm thinking we may want to do is provide a minimal interface--turn the time integer into a string rep or split out into an array, something like: localtime Sx, Iy gmtime Sx, Iy You almost have to provide at least these, as you have to deal with how various OS's handle the hardware clock. Windows insists that the hardware clock be set to localtime, Solaris and most U*x's insist that it be set to GMT, while Linus supports setting it to either. This also means that the simple second-sense-epoc time() may not be so simple after all. -- Mark Biggar [EMAIL PROTECTED]
Re: Dates and Times
On Wed, Mar 03, 2004 at 11:37:09AM -0500, Dan Sugalski wrote: : FWIW, if we start getting into the What should our base time for the : epoch be arguments, I'll warn you that the answer if I have to make : one is probably Nov 17, 1858 at midnight, give or take a bad memory, : and our time value'll be a 64-bit integer. So think carefully before : you go there. :) Well, you can do whatever you like with Parrot, but I want Perl 6's standard interface to be floating point seconds since 2000. Floating point will almost always have enough precision for the task at hand, and by the time it doesn't, it will. :-) But the overriding consideration is that normal users should Inever have to remember the units of the fractional seconds. Is it nanoseconds this week? That's the sort of arbitrary complexity that doesn't belong in Perl 6. Solving the real problems is hard enough. Larry
Re: Dates and Times
At 6:03 PM + 3/3/04, [EMAIL PROTECTED] wrote: What I'm thinking we may want to do is provide a minimal interface--turn the time integer into a string rep or split out into an array, something like: localtime Sx, Iy gmtime Sx, Iy You almost have to provide at least these, as you have to deal with how various OS's handle the hardware clock. Windows insists that the hardware clock be set to localtime, Solaris and most U*x's insist that it be set to GMT, while Linus supports setting it to either. This also means that the simple second-sense-epoc time() may not be so simple after all. Gah. OK, I'm about to declare that the time op *always* returns time as GMT, though without specifying an epoch, unless someone's got a good reason not to. That takes at least one variable out of the problem. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Dates and Times
At 10:29 AM -0800 3/3/04, Larry Wall wrote: But the overriding consideration is that normal users should Inever have to remember the units of the fractional seconds. Is it nanoseconds this week? Right, the units will always be seconds. That, at least, will stay constant. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Dates and Times
On Wed, 3 Mar 2004, Dan Sugalski wrote: FWIW, if we start getting into the What should our base time for the epoch be arguments, I'll warn you that the answer if I have to make one is probably Nov 17, 1858 at midnight, give or take a bad memory, and our time value'll be a 64-bit integer. So think carefully before you go there. :) TAI is 1958-01-01T00:00:00. -J --
Re: Dates and Times
On Wed, 3 Mar 2004, Larry Wall wrote: Well, you can do whatever you like with Parrot, but I want Perl 6's standard interface to be floating point seconds since 2000. Floating point will almost always have enough precision for the task at hand, and by the time it doesn't, it will. :-) Aren't there enough epochs already? :) Anyways, I recall some discussion on p6l from years ago about using TAI (and I think specifically libtai) as the internal time format for p6. Is this still the case? It would be *really* nice to be able to rely on getting TAI from Parrot. -J --
Re: Dates and Times
At 10:13 AM -1000 3/3/04, Joshua Hoblitt wrote: On Wed, 3 Mar 2004, Dan Sugalski wrote: FWIW, if we start getting into the What should our base time for the epoch be arguments, I'll warn you that the answer if I have to make one is probably Nov 17, 1858 at midnight, give or take a bad memory, and our time value'll be a 64-bit integer. So think carefully before you go there. :) TAI is 1958-01-01T00:00:00. And that's a good base time too, other than it being off of clock time for everyone by 32 seconds, give or take. Tempting, though. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Dates and Times
On Wed, Mar 03, 2004 at 10:21:37AM -1000, Joshua Hoblitt wrote: : On Wed, 3 Mar 2004, Larry Wall wrote: : : Well, you can do whatever you like with Parrot, but I want Perl 6's : standard interface to be floating point seconds since 2000. Floating : point will almost always have enough precision for the task at hand, : and by the time it doesn't, it will. :-) : : Aren't there enough epochs already? :) Aren't there enough programming languages already? :-) : Anyways, I recall some discussion on p6l from years ago about using : TAI (and I think specifically libtai) as the internal time format : for p6. Is this still the case? As I said, I don't care what the internal time format is. I'm just sticking up for the average user of the next millenium. It's my gut-level feeling that 99% of users would prefer that continuous time be represented by a pseudo-continuous type like floating pint, and that we should all settle on an epoch that will still be easy to remember in the year 2149. So I think the default public interface needs to be floating point seconds since 2000. : It would be *really* nice to be able to rely on getting TAI from Parrot. It would also be really nice to be able to rely on not having to write FAQs telling people how to deal with interfaces that are more complicated than they need to be. :-) Don't get me wrong--I think the concept of TAI time is great. It's just always going to be a fixed number of seconds different than Perl 6 time, is all, whatever the TAI time is for Jan 1, 2000, UTC. Yes, I'm a megalomaniac to think that I can set a better standard than the French... :-) Larry
Re: Dates and Times
At 12:59 PM -0800 3/3/04, Larry Wall wrote: On Wed, Mar 03, 2004 at 10:21:37AM -1000, Joshua Hoblitt wrote: : On Wed, 3 Mar 2004, Larry Wall wrote: : Anyways, I recall some discussion on p6l from years ago about using : TAI (and I think specifically libtai) as the internal time format : for p6. Is this still the case? As I said, I don't care what the internal time format is. I'm just sticking up for the average user of the next millenium. It's my gut-level feeling that 99% of users would prefer that continuous time be represented by a pseudo-continuous type like floating pint, and that we should all settle on an epoch that will still be easy to remember in the year 2149. So I think the default public interface needs to be floating point seconds since 2000. Reasonable enough, though there's something to be said for a completely meaningless (to most people) epoch so folks stop treating the number as a number with meaning and instead treat it as a black box thing they can do offset math with. Don't get me wrong--I think the concept of TAI time is great. It's just always going to be a fixed number of seconds different than Perl 6 time, is all, whatever the TAI time is for Jan 1, 2000, UTC. That, as they say, turns out not to be the case. UTC has leap seconds, TAI doesn't. The two are slowly diverging--off by 32 seconds right now, and probably off by 33 this year or next, with extra seconds added irregularly. (It's why the decoded time array's seconds goes from 0-60 rather than 0-59) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Dates and Times
Oracle actually has the most elegant Gregorian time manipulation implementation I've seen. The only operations it really supports are add_months and add_days. Year +/- can be implemented with add_months*12. All of add_week|hour|minute|second|ms|us|ns can be synthesized from add_days. This scarcity of operations yields the elegance, and is perfect for an instruction set. Based on that model, I'd suggest: gmclock(out Nx) UTC clock in seconds since hrs Jan 1, 2000, ignoring leap seconds. gmtime(out Px, in Nx) Splits date up like Perl 5 gmtime. (But without annoying y -= 1900 and m -= 1?) localtime(out Px, in Nx) Splits date up like Perl 5 localtime. (But without annoying y -= 1900 and m -= 1?) add_months(out Nx, in Ny, in Nz) Sets x to y + z months. That's the minimal core set of operations. But the redundancy of gmtime and localtime has always bothered me, so I could see this instead: gmclock(out Nx) UTC clock in seconds since hrs Jan 1, 2000, ignoring leap seconds. tolocal out Nx, out Iy, in Nz x is set to z converted to the local time zone. y - 1 if Daylight Savings Time was in effect at z; y - 0 otherwise. splittime Px, Nx Splits date up like Perl 5 gmtime. (But without annoying y -= 1900 and m -= 1?) add_months(out Nx, in Ny, in Nz) Sets x to y + z months. By contrast, date manipulation in Perl 5 is truly horrid. I've seen modules which turned a gmtime array back into an epoch-base value by using localtime to converge on the correct value using progressive approximation, as if finding the root of an arbitrary mathematical function. Doing the same using the above instructions can easily be implemented in 17 instructions flat with no branches: # out Nx: clock-style seconds-since-epoch # in Py: splittime-style array # Nz: temp Nx = 0 # years Nz = Py[5] Nz = Nz - 2000# epoch based at year 2000 Nz = Nz * 12 # = months per year add_months Nx, Nx, Nz # months Nz = Py[4] add_months Nx, Nx, Nz # days Nz = Py[3] Nz = Nz * 86400 # = 24 * 60 * 60 seconds per day Nx = Nx + Nz # hours Nz = Py[2] Nz = Nz * 3600 # = 60 * 60 seconds per hour Nx = Nx + Nz # minutes Nz = Py[1] Nz = Nz * 60 # = 60 seconds per minute Nx = Nx + Nz # seconds Nz = Py[0] Nx = Nx + Nz Leave parsing and formatting entirely to libraries. Absolutely no need for that in the instruction set. -- Gordon Henriksen IT Manager ICLUBcentral Inc. [EMAIL PROTECTED]
Re: Dates and Times
On Wed, Mar 03, 2004 at 04:18:14PM -0500, Dan Sugalski wrote: : Don't get me wrong--I think the concept of TAI time is great. : It's just always going to be a fixed number of seconds different than : Perl 6 time, is all, whatever the TAI time is for Jan 1, 2000, UTC. : : That, as they say, turns out not to be the case. UTC has leap : seconds, TAI doesn't. The two are slowly diverging--off by 32 seconds : right now, and probably off by 33 this year or next, with extra : seconds added irregularly. (It's why the decoded time array's seconds : goes from 0-60 rather than 0-59) No, I *am* assuming that Perl 6 time tracks TAI time accurately with a constant offset, and drifts with respect to UTC. That does mean that the translations from internal time to real datetimes have to be groomed periodically, and people who don't upgrade their Perl for years on end might find its clock off by a second or two. But just as the cable company forces periodic upgrades into your cable box without your keeping track, any networked Perl ought to be able to install a new time map automatically over the net without much user intervention--but only if we design with that in mind in the first place. But for sanity's sake, to keep the time continuum flat, we have to abandon the notion that Dec 31 is always 86400 seconds long, or any length predictable several years in advance. We can't afford to have off-by-one errors when you subtract two standard Perl 6 times. Larry
Re: Dates and Times
Dan Sugalski [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Reasonable enough, though there's something to be said for a completely meaningless (to most people) epoch so folks stop treating the number as a number with meaning and instead treat it as a black box thing they can do offset math with. Don't make a decision when you don't need to. Perhaps the thing to do is to not return a number at all: just return a time black box that knows how to subtract an epoch black-box (also of type time), resulting in a value that is the number of seconds since the epoch. Supply various epoch black-boxes as constants. Dave.
Re: Dates and Times
Dan Sugalski [EMAIL PROTECTED] wrote: At 10:13 AM -1000 3/3/04, Joshua Hoblitt wrote: TAI is 1958-01-01T00:00:00. And that's a good base time too, other than it being off of clock time for everyone by 32 seconds, give or take. Tempting, though. Bahh, these few seconds. Dan, the year, the year is that what counts. Good year, though. leo, SCNR
Re: Dates and Times
On Wed, 3 Mar 2004, Dan Sugalski wrote: At 12:59 PM -0800 3/3/04, Larry Wall wrote: On Wed, Mar 03, 2004 at 10:21:37AM -1000, Joshua Hoblitt wrote: : On Wed, 3 Mar 2004, Larry Wall wrote: : Anyways, I recall some discussion on p6l from years ago about using : TAI (and I think specifically libtai) as the internal time format : for p6. Is this still the case? As I said, I don't care what the internal time format is. I'm just sticking up for the average user of the next millenium. It's my gut-level feeling that 99% of users would prefer that continuous time be represented by a pseudo-continuous type like floating pint, and that we should all settle on an epoch that will still be easy to remember in the year 2149. So I think the default public interface needs to be floating point seconds since 2000. UTC may stop having leapseconds all together. :) That would make the year 2000 epoch attractive as negative values would have leapseoncds while positive values would not. The problem is that Wall's Clock system is going to have to documented and explained as much as another other choice would. That, as they say, turns out not to be the case. UTC has leap seconds, TAI doesn't. The two are slowly diverging--off by 32 seconds right now, and probably off by 33 this year or next, with extra seconds added irregularly. (It's why the decoded time array's seconds goes from 0-60 rather than 0-59) It actually needs to goto 61 to properly support UTC. :) -J --
Re: Dates and Times
On Wed, 3 Mar 2004, Dan Sugalski wrote: Gah. OK, I'm about to declare that the time op *always* returns time as GMT, though without specifying an epoch, unless someone's got a good reason not to. That takes at least one variable out of the problem. The GMT system is dead... do you mean UTC or UT1? :) -J --
Re: Dates and Times
At 2:19 PM -1000 3/3/04, Joshua Hoblitt wrote: On Wed, 3 Mar 2004, Dan Sugalski wrote: At 12:59 PM -0800 3/3/04, Larry Wall wrote: On Wed, Mar 03, 2004 at 10:21:37AM -1000, Joshua Hoblitt wrote: : On Wed, 3 Mar 2004, Larry Wall wrote: : Anyways, I recall some discussion on p6l from years ago about using : TAI (and I think specifically libtai) as the internal time format : for p6. Is this still the case? As I said, I don't care what the internal time format is. I'm just sticking up for the average user of the next millenium. It's my gut-level feeling that 99% of users would prefer that continuous time be represented by a pseudo-continuous type like floating pint, and that we should all settle on an epoch that will still be easy to remember in the year 2149. So I think the default public interface needs to be floating point seconds since 2000. UTC may stop having leapseconds all together. :) That would make the year 2000 epoch attractive as negative values would have leapseoncds while positive values would not. The problem is that Wall's Clock system is going to have to documented and explained as much as another other choice would. Interesting -- so the planet's finally gotten its act together and settled on a rotational speed, huh? Cool. :) That, as they say, turns out not to be the case. UTC has leap seconds, TAI doesn't. The two are slowly diverging--off by 32 seconds right now, and probably off by 33 this year or next, with extra seconds added irregularly. (It's why the decoded time array's seconds goes from 0-60 rather than 0-59) It actually needs to goto 61 to properly support UTC. :) Really? I didn't realize that there were any days where there were two extra seconds added. How... inconvenient. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Dates and Times
At 2:21 PM -1000 3/3/04, Joshua Hoblitt wrote: On Wed, 3 Mar 2004, Dan Sugalski wrote: Gah. OK, I'm about to declare that the time op *always* returns time as GMT, though without specifying an epoch, unless someone's got a good reason not to. That takes at least one variable out of the problem. The GMT system is dead... do you mean UTC or UT1? :) Y'know, I'm not sure. UTC, I expect, if GMT is well and truly dead. Whatever gmtime and its ilk in the C runtime return. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Dates and Times
For those of you not up to speed on how much date and time confusion there is, I remember this article by Dave Rolsky as being interesting: http://www.perl.com/pub/a/2003/03/13/datetime.html
