Re: Grand Unified Theory of Date/Time modules
On Mon, 3 Feb 2003 [EMAIL PROTECTED] wrote: There is something else to consider. What does a timestamp of May 5, 1776, 4:16:23 PM actually _mean_? For May 5, 1976, 4:16:23 PM, it's clear which point in time we mean when we have the timezone. But for dates 200 years ago, it isn't so clear. When it was 4 PM here, it would have been 4:10 PM in the next town, and 3:55 in a town in the other direction. Second or even minute precision doesn't make much sense for long ago dates if you don't have a geographical location as well. And it becomes even more difficult if you go back further in time. There was a time when a night lasted 12 hours, a day 10, and one hour both for dusk and dawn. What do 'seconds' mean for such dates? Yeah, there's a general problem with thinking about pre-time zone datetimes in modern terms. The time zone code I've written does include all the historical data, but since one are (America/Chicago) is used to represent a large region (all of the midwest US), it kind of breaks down when you get back far enough to be in LMT (local mean time), because you get the LMT for Chicago, not Minneapolis or New Orleans or Fargo. Users who really wanted accurate town to town time zone differences could calculate the actual LMT and then use the DateTime::TimeZone::OffsetOnly module (which lets you just specify a fixed offset like -21514) for datetimes in different towns. Alternately, if you aren't going to be creating times based on local times in multiple locations, then you can just say everything is UTC. This works if you just want to figure out how many months are between May, 1776 and June, 1976, which could be done like this: my $j1976 = DateTime-new( year = 1976, month = 6, time_zone = 'UTC' ); my $m1776 = DateTime-new( year = 1776, month = 5, time_zone = 'UTC' ); my $duration = $j1976 - $m1776; print There were , $duration-months, between the two dates\n; This should work with the existing code in CVS. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Grand Unified Theory of Date/Time modules
On Tue, Jan 28, 2003 at 02:37:31PM +1100, Rick Measham wrote: There are two time periods that do not change: Years (time the earth takes to travel around the sun) and Days (time the earth take to spin one complete revolution). But they do change. If the length of a day was constant, we would not have leap seconds. However, we do. Also, the time it takes for the earth to travel around the sun isn't constant, but that's irrelevant. The years used in calenders used by humans typically count an integer number of days, and not the irrational number of days it takes for the earth to travel around the sun. I'm pretty sure 2004 won't have the same length as 2003. Abigail
Re: Grand Unified Theory of Date/Time modules
[EMAIL PROTECTED] (Rick Measham) wrote: There are two time periods that do not change: Years (time the earth takes to travel around the sun) and Days (time the earth take to spin one complete revolution). I'd suggest that these the the two values that DateTime keeps internally. The 'year' would be an integer delta from some Epoch (BC/1970) and the 'day' would be a float representing how many days since the start of the year value. Different calendars have very different ideas about what is a year, but pretty much every calendar has the notion of a day, so I'd go for using just the day and time of day. An example: Store the date as an array of two integers [N1, N2], where N1 is the days since some fixed date and N2 is the time of day. Then, even if both N1 and N2 must be in the interval [-2^31, 2^31-1] (to avoid overflow), you can let N2 be the nanoseconds, and thus one can represent any point in time within more than +/-5 million years with nanosecond precision using integers only! This representation is much smaller than storing year, month, day, hours, minutes, etc. as separate values, and this representation can easily be converted to a Gregorian date (and back) with a few lines of pure integer arithemtic. Peter PS. If you let N1 and N2 be IEEE doubles, which use 53 bits in the mantissa, then one can represent any point in time within more than +/- 9 million billion years with femtosecond (1e-15) precision, just by using two integers. -- #!/local/bin/perl5 -wp -*- mode: cperl; coding: iso-8859-1; -*- # matlab comment stripper (strips comments from Matlab m-files) s/^((?:(?:[])}\w.]'+|[^'%])+|'[^'\n]*(?:''[^'\n]*)*')*).*/$1/x;
Re: Grand Unified Theory of Date/Time modules
On Mon, 27 Jan 2003, Peter J. Acklam wrote: [EMAIL PROTECTED] (Rich Bowen) wrote: On Sun, 6 May 2001 03:35:15 +0530, Abhijit Menon-Sen said: Have you seen the TAI64* formats at URL:http://cr.yp.to/time.html? (I am supposedly writing Time::TAI64.) Hmm. attosecond accuracy? What real-world application really needs that sort of thing? Physicists. The expected life-span of a top quark is 0.4 zs, which is less than one millionth of 1 as. And they use Perl for their calculations? -- Nothing is perfekt. Certainly not me. Success to failure. Just a matter of degrees.
Re: Grand Unified Theory of Date/Time modules
On Tue, 28 Jan 2003, Peter J. Acklam wrote: [I know this is a very old posting, but I just can't resist commenting it since it is about the base time format.] It seems a little irrelevant, and perhaps even unfair, to start rebutting comments that I made going on 2 years ago. A lot has happened since then, and we've made a lot of progress since then. The note that you're commenting on represents the *beginning* of the discussion, and addresses points that have been rehashed numerous times. Returning to the beginning does not serve our purposes a whole lot. [EMAIL PROTECTED] (Rich Bowen) wrote: [...] the fact that an ISO date can be expressed 6 different ways, which makes ISO less attractive to me. I don't see why this is relevant. A date may be represented in many more than six ways, but as long as one picks one format and everyone agrees to use that, then it's no longer a problem. This was my point, if you look at the larger context - the need to pick a single format for the internal representation. Julian dates, for example, require that you store the time as a separate field, because the julian date expresses only the date. It is *very* common to include a fractional part to represent the time of day. And by allowing an arbitrary number of decimals in the fractional part (and an arbitrary number of digits in the integer part) one can represent *any* point in time with *any* precision. Yes, and we frequently encountered round-off errors. Compared to Julian days, the iCalendar format is clumsy, awkward, and limited. These terms represent opinion, and are not useful for measuring anything particular. I find it neither clumsy nor awkward, and I don't find it limiting because I never have to deal with times of greater precision. However, once again, this is a point that we debated into the ground, and came up with practical solutions for. While I've read this various places, I've never encountered a real application where microsecond precision was necessary in a calendaring context. Is the DateTime-modules only for calendaring purposes? I thought this was a base on which people could build modules for doing all sorts of time calculations. Hm. Perhaps I misunderstood. It's for whatever you want to use it for. There will be no accompanying license that requires you to use it for particular purposes. I was merely stating my personal experience in my area of interest. If other people want to add support for a finer granularity of time representation, I've never opposed that. -- DrBacchus Context? fajita It's the first verse of the chapter. There is no context. (#apache on irc.freenode.net)
Re: Grand Unified Theory of Date/Time modules
On Tue, 28 Jan 2003, Peter J. Acklam wrote: [EMAIL PROTECTED] (Eugene Van Der Pijll) wrote: Timestamps with a precision better than an attosecond are never needed, as far as I know. Physicists work with as, ys and zs, but only with time lengths or intervals, not with absolute time. That's probably true -- and the example I gave was, admittedly, rather example -- but it was intended as a counter-example to the statement someone made that attoseconds are never used in the real world. That was not the statement. What I said was that *I* had never encountered a use for them in my experience. I hardly deny the existence of such uses. Anyway, whatever base format is used, I hope that it has a large enough range and resolution/granularity. If not, then people will be more tempted to write even more (incompatible) time and date modules. You seem to be assuming that it *won't*. It will. It does. This issue has been discussed to death. We want fine granularity. Fine. Nobody has suggested otherwise. -- Rich Bowen - [EMAIL PROTECTED] ... and another brother out of his mind, and another brother out at New York (not the same, though it might appear so) Somebody's Luggage (Charles Dickens)
Re: Grand Unified Theory of Date/Time modules
On Tue, 28 Jan 2003, Peter J. Acklam wrote: [EMAIL PROTECTED] (Rick Measham) wrote: There are two time periods that do not change: Years (time the earth takes to travel around the sun) and Days (time the earth take to spin one complete revolution). I'd suggest that these the the two values that DateTime keeps internally. The 'year' would be an integer delta from some Epoch (BC/1970) and the 'day' would be a float representing how many days since the start of the year value. Different calendars have very different ideas about what is a year, but pretty much every calendar has the notion of a day, so I'd go for using just the day and time of day. An example: Store the date as an array of two integers [N1, N2], where N1 is the days since some fixed date and N2 is the time of day. Then, even if both N1 and N2 must be in the interval [-2^31, 2^31-1] (to avoid overflow), you can let N2 be the nanoseconds, and thus one can represent any point in time within more than +/-5 million years with nanosecond precision using integers only! Yes, that's how we're doing it, and is how we have been doing it for a long long time. It's the format that I recommended in an earlier note (Julian date, plus another number for time) and which we subsequently implemented in Date::ICal. -- Rich Bowen - [EMAIL PROTECTED] ... and another brother out of his mind, and another brother out at New York (not the same, though it might appear so) Somebody's Luggage (Charles Dickens)
Re: Grand Unified Theory of Date/Time modules
On Tue, 28 Jan 2003, John Peacock wrote:
Tell you what; I'll write an implementation of my way (probably in XS) and we'll
compare. I think you're mistaken; your storage methods requires conversion for
all nontrivial operations (e.g. $dt-year), whereas mine only needs a conversion
when changing bases (e.g. $dt-eastern_orthodox_easter). The only issue I need
to deal with is determining which sub's compromise the actual implementation and
which are producing values derivable from those subs. Going forward, it would
be a very good idea to restructure the code so that this is obvious. I would
even suggest going ahead and pulling all of the internals code out of the base
module and create a default implementation module.
Well, an XS implementation is quite likely to beat pure Perl, even if you
used RD days as well.
But I would certainly welcome an XS implementation of the DateTime API.
In fact, having such a thing is a big goal of mine. As long as it can
produce Rata Die days on command, it's all good.
And yes, the code can definitely be cleaned up with regards to what needs
access to internal representation and what doesn't. In fact, we should
probably start using a _rata_die method internally to avoid relying on
$self-{rd_days} so a subclass can inherit all the component methods from
the parent.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: Grand Unified Theory of Date/Time modules
Rich Bowen [EMAIL PROTECTED] wrote: On Tue, 28 Jan 2003, Peter J. Acklam wrote: [I know this is a very old posting, but I just can't resist commenting it since it is about the base time format.] It seems a little irrelevant, and perhaps even unfair, to start rebutting comments that I made going on 2 years ago. A lot has happened since then, and we've made a lot of progress since then. The note that you're commenting on represents the *beginning* of the discussion, and addresses points that have been rehashed numerous times. Returning to the beginning does not serve our purposes a whole lot. I searched the archives and read a whole lot of postings, but didn't find anything about what I wrote, so that's why I posted it. I wanted to join this project and contribute something, but first I wanted to understand the reason behind some of the design decisions made, hence my postings and questions. But never mind, I'll shut up. Peter -- #!/local/bin/perl5 -wp -*- mode: cperl; coding: iso-8859-1; -*- # matlab comment stripper (strips comments from Matlab m-files) s/^((?:(?:[])}\w.]'+|[^'%])+|'[^'\n]*(?:''[^'\n]*)*')*).*/$1/x;
Re: Grand Unified Theory of Date/Time modules
On Tue, 28 Jan 2003, Peter J. Acklam wrote: I searched the archives and read a whole lot of postings, but didn't find anything about what I wrote, so that's why I posted it. I wanted to join this project and contribute something, but first I wanted to understand the reason behind some of the design decisions made, hence my postings and questions. But never mind, I'll shut up. Please let's calm down. I think it's fair to say that yes, this stuff has been discussed, and yes, the archives are now _really_ big so finding this may be difficult. I hope you're still interested in participating. As to sub-second resolutions. Let's settle this simply right now. This _will_ be supported at the core level. The fineness of resolution is yet to be determined. And the implementation (floating point versus an additional scalar parameter) is also undetermined. But I really don't want to worry about that right now. Implementing this will be relatively simple compared to some of the stuff that I'm working on right now, like time zones and (soon) leap seconds. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Grand Unified Theory of Date/Time modules
On Tue, 28 Jan 2003, Peter J. Acklam wrote: Rich Bowen [EMAIL PROTECTED] wrote: On Tue, 28 Jan 2003, Peter J. Acklam wrote: [I know this is a very old posting, but I just can't resist commenting it since it is about the base time format.] It seems a little irrelevant, and perhaps even unfair, to start rebutting comments that I made going on 2 years ago. A lot has happened since then, and we've made a lot of progress since then. The note that you're commenting on represents the *beginning* of the discussion, and addresses points that have been rehashed numerous times. Returning to the beginning does not serve our purposes a whole lot. I searched the archives and read a whole lot of postings, but didn't find anything about what I wrote, so that's why I posted it. I wanted to join this project and contribute something, but first I wanted to understand the reason behind some of the design decisions made, hence my postings and questions. But never mind, I'll shut up. That was not my intention. Some of this discussion may also be found over on the Reefknot mailing list. When things were not progressing very effectively here, most of the actual work moved over to the reefknot project, which produced excellent code for about a year, and then somewhat evaporated. My remarks were merely intended to point out that an awful lot of time and bits are being wasted on this mailing list discussing the same things over and over again. I'm sorry if you bore the brunt of my frustration on that point. I will attempt to direct my rants a little better in the future. ;-) -- Rich Bowen - [EMAIL PROTECTED] As we trace our own few circles around the sun We get it backwards and our seven years go by like one Dog Years (Rush - Test for Echo - 1999)
Re: Grand Unified Theory of Date/Time modules
Dave Rolsky wrote: Well, an XS implementation is quite likely to beat pure Perl, even if you used RD days as well. Don't tell anyone, but my first pass will be pure Perl, since I am still pretty much an XS newbie... John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: Grand Unified Theory of Date/Time modules
On Tue, 28 Jan 2003, John Peacock wrote: Dave Rolsky wrote: Well, an XS implementation is quite likely to beat pure Perl, even if you used RD days as well. Don't tell anyone, but my first pass will be pure Perl, since I am still pretty much an XS newbie... Hehe, that's fine. My guess is that this is probably a much easier way to write an XS module, since all you'll have to do is re-implement the same logic in C, which leaves you free to _only_ think about all the low-level C crap you have to deal with, as opposed to trying to think about low and high level concerns at the same time. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Grand Unified Theory of Date/Time modules
Dave Rolsky wrote: Hehe, that's fine. My guess is that this is probably a much easier way to write an XS module, since all you'll have to do is re-implement the same logic in C, which leaves you free to _only_ think about all the low-level C crap you have to deal with, as opposed to trying to think about low and high level concerns at the same time. Hey! I thought you were doing all of the high level thinking here! duck John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: Grand Unified Theory of Date/Time modules
On Tue, 28 Jan 2003, John Peacock wrote: Hehe, that's fine. My guess is that this is probably a much easier way to write an XS module, since all you'll have to do is re-implement the same logic in C, which leaves you free to _only_ think about all the low-level C crap you have to deal with, as opposed to trying to think about low and high level concerns at the same time. Hey! I thought you were doing all of the high level thinking here! duck Well, I'm just going to claim credit for it ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Grand Unified Theory of Date/Time modules
[EMAIL PROTECTED] (Rich Bowen) wrote: On Sun, 6 May 2001 03:35:15 +0530, Abhijit Menon-Sen said: Have you seen the TAI64* formats at URL:http://cr.yp.to/time.html? (I am supposedly writing Time::TAI64.) Hmm. attosecond accuracy? What real-world application really needs that sort of thing? Physicists. The expected life-span of a top quark is 0.4 zs, which is less than one millionth of 1 as. Peter -- #!/local/bin/perl5 -wp -*- mode: cperl; coding: iso-8859-1; -*- # matlab comment stripper (strips comments from Matlab m-files) s/^((?:(?:[])}\w.]'+|[^'%])+|'[^'\n]*(?:''[^'\n]*)*')*).*/$1/x;
Re: Grand Unified Theory of Date/Time modules
On Tue, 28 Jan 2003, Peter J. Acklam wrote: [...] the fact that an ISO date can be expressed 6 different ways, which makes ISO less attractive to me. I don't see why this is relevant. A date may be represented in many more than six ways, but as long as one picks one format and everyone agrees to use that, then it's no longer a problem. The iCalendar format is much worse because it is too limited to be suitable as a base format. It might be ok for everyday calendar use, but not as a base format for a set of modules that might be used by people with all sorts of needs related to range and precision: Astronomers work with dates long before year 1 and physicists work with atto, yotta, zettaseconds. Date::ICal never used ICal format internally anyway, I should point out. Julian dates, for example, require that you store the time as a separate field, because the julian date expresses only the date. It is *very* common to include a fractional part to represent the time of day. And by allowing an arbitrary number of decimals in the fractional part (and an arbitrary number of digits in the integer part) one can represent *any* point in time with *any* precision. And Julian days are very convenient for time arithmetic. And they are calendar independent -- a good gratest common divisor. Compared to Julian days, the iCalendar format is clumsy, awkward, and limited. See above. Anyway, the current internals have Rata Die days (basically JD or MJD but with a different 0 day) and seconds into the day. Making seconds fractional is obviously not a big problem. At least one person object to fractional seconds (and preferred storing something like attoseconds separately) but I can't remember why. And it sure makes the implementation hairier. While I've read this various places, I've never encountered a real application where microsecond precision was necessary in a calendaring context. Is the DateTime-modules only for calendaring purposes? I thought this was a base on which people could build modules for doing all sorts of time calculations. Hm. Perhaps I misunderstood. I'd like it to work for lots of stuff, but if _all_ you need is attoseconds, then it's not going to be a very good fit. Do physicists need to record dates and times with attosecond precision, or do they need to record a date and time, and seperately record experiment data which includes attoseconds? See the difference? Making it work for calendaring purposes is definitely the first goal. If it can also be used for other things that is good. But what other things are you thinking of? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Grand Unified Theory of Date/Time modules
On Tue, 28 Jan 2003, Eugene van der Pijll wrote: On the other hand, I would like to be able to specify a date with a precision of less than a day. For example, the date 1815, or july 1974. But I'll write my own module around DateTime that can handle these dates, if necessary. You'll probably need to write your own module around DateTime.pm. For example, how do you handle adding 3 days to july 1974? How about 31 days? I don't think time arithmetic (adding a couple of seconds to a certain time) should be done with floating point arithmetic. And calendar independence sounds like a good idea, but most applications will work with only one or two calendars, mostly the Gregorian one. An internal format based on the Gregorian calendar will prevent many conversions. The internal format is Rata Die days, which can be converted to quite a number of calendars using known algorithms. I do agree that calendaring shouldn't be the only purpose of DateTime. I don't think people who need attosecond would bother with a module that knows about time zones and Julian calendars. They would just use scalar values as seconds. That's what I was thinking too. (Yes, I know Rich said microseconds. But I can imagine that kind of precisions being important. But you have to draw the line somewhere.) I'll implement whatever is agreed upon (or better yet, apply patches), since I for one can't think of anything I'm working on that needs sub-second precision. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Grand Unified Theory of Date/Time modules
Dave Rolsky wrote: You'll probably need to write your own module around DateTime.pm. For example, how do you handle adding 3 days to july 1974? How about 31 days? I think that we should treat this as 3 + undef, since the date in question did not specify a day, only a month. So I would either return july 1974 (plus a warning) or throw an error (Date does not have enough precision). This leads me nicely into what I've been thinking about. There was a discussion on this list about temporal granularity back in May 2001: http:[EMAIL PROTECTED]/msg00045.html which was mostly part of the original What's our Name Space??? discussion. However, I find the concept itself very appealing for the present discussion of storage methods. For example, if a geologist wants to use a DateTime object, he is only interested in years (and millions of them) and not what time it was (apologies to Bishop Usher). Similarly, someone writing a business calendar (how many days until I get paid for this job) is not going to care about attoseconds. Someone writing a realtime event program may only want to know how many seconds have elapsed since some previous time. Each user will have a different granularity of interest. Hence, it would seem to me to make the most sense to store the basic DateTime object as an array of (possibly undefined) periods: years, months, days, hours, minutes, seconds, etc. By doing it this way, instead of some sort of days since some epoch, any date or in fact any time differences are trivial. And by storing the data in an array from most to least significant values, it would be possible to ignore meaningless distinctions where appropriate. I hear the gnashing of teeth out there already: But what about leap seconds? and What about different TZ calculations? This doesn't preclude handling those appropriately, when called for. If someone cares about how many seconds there are between two DateTime objects, and both objects are defined with seconds, then both the TZ and leap seconds come into play. If only one object has seconds, my gut says give an answer with a supressable warning that accuracy has been lost; if neither are precise enough, die screaming. On the other hand, if someone wants to know how many months there were between May, 1776 and June, 1976, it seems less than helpful to convert to Rata Die or seconds (or heavens be, attoseconds ;~) to store the data, then subtracting and finally dividing repeatedly, just to get the answer 200*12 + 1. Sure, there are lots of useful formulas to go from Rata Die to other date formats; store that too, as a cached value. Or just convert to that when going to other formats (my preferred method). Those are going to be the exceptional cases. The general case is someone who wants to calculate hours between something, days until my birthday, years since Lincoln died. John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: Grand Unified Theory of Date/Time modules
On 28/1/03 1:20 pm, John Peacock at [EMAIL PROTECTED] spake thus: Hence, it would seem to me to make the most sense to store the basic DateTime object as an array of (possibly undefined) periods: years, months, days, hours, minutes, seconds, etc. By doing it this way, instead of some sort of days since some epoch, any date or in fact any time differences are trivial. And by storing the data in an array from most to least significant values, it would be possible to ignore meaningless distinctions where appropriate. My argument against this is due to the multitude of time representations that the module should be able to work with - without heaps of calculations. Storing 'Months' is useful for Gregorian calendars, but is annoyingly useless for decimal calendars. There are two time periods that do not change: Years (time the earth takes to travel around the sun) and Days (time the earth take to spin one complete revolution). I'd suggest that these the the two values that DateTime keeps internally. The 'year' would be an integer delta from some Epoch (BC/1970) and the 'day' would be a float representing how many days since the start of the year value. This makes things just as easy for every calendar: Decimal: Basically this format is already decimal Gregorian: Date comes from the integer and the time from the following fraction over 24. Likewise any other calendar that is needed could be determined from these two imovable periods. Just my $0.02 Cheers! Rick Measham P.S. Storing Years/Days also make the module transportable .. every planet in the universe has a day and a year and thus could use the module without huge changes :) There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners
Re: Grand Unified Theory of Date/Time modules
On Mon, 27 Jan 2003, John Peacock wrote: Hence, it would seem to me to make the most sense to store the basic DateTime object as an array of (possibly undefined) periods: years, months, days, hours, minutes, seconds, etc. By doing it this way, instead of some sort of days since some epoch, any date or in fact any time differences are trivial. And by storing the data in an array from most to least significant values, it would be possible to ignore meaningless distinctions where appropriate. So you want to greatly complicate the internals (and slow it down, I'd bet), for what? With the current implementation, you can get the effect of a day-sized granularity by creating dates like this: my $dt = DateTime-new( year = 1965, month = 10, day = 1, floating = 1 ); Setting the datetime as floating will mean there is no TZ or leap second calculation done, so as long as you just do math with the same high granularity, you're all set. Now, if someone wants to create a subclass or container class to _enforce_ the granularity, that's cool. But what exists right now will work quite well for this. I think the same goes for months and years. I wouldn't necessarily object to allowing this: my $dt = DateTime-new( year = 1965 ); Again, this could give the illusion of year-sized granularity. On the other hand, if someone wants to know how many months there were between May, 1776 and June, 1976, it seems less than helpful to convert to Rata Die or seconds (or heavens be, attoseconds ;~) to store the data, then subtracting and finally dividing repeatedly, just to get the answer 200*12 + 1. Except that it could greatly complicate all sorts of other things. cases. The general case is someone who wants to calculate hours between something, days until my birthday, years since Lincoln died. All of which are totally doable with the current code. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Grand Unified Theory of Date/Time modules
[EMAIL PROTECTED] (Eugene Van Der Pijll) wrote: Timestamps with a precision better than an attosecond are never needed, as far as I know. Physicists work with as, ys and zs, but only with time lengths or intervals, not with absolute time. That's probably true -- and the example I gave was, admittedly, rather example -- but it was intended as a counter-example to the statement someone made that attoseconds are never used in the real world. Anyway, whatever base format is used, I hope that it has a large enough range and resolution/granularity. If not, then people will be more tempted to write even more (incompatible) time and date modules. Peter -- #!/local/bin/perl5 -wp -*- mode: cperl; coding: iso-8859-1; -*- # matlab comment stripper (strips comments from Matlab m-files) s/^((?:(?:[])}\w.]'+|[^'%])+|'[^'\n]*(?:''[^'\n]*)*')*).*/$1/x;
