Peter J. Acklam schreef: > 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.
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. As you wrote in another post, the expected life-span of a top quark is 0.4 zs. But this is not measured by taking the formation time of the top quark, say "2003-01-28 00:45:56.1234567890123456789 UTC", and subtracting that from the decay time of "2003-01-28 00:45:56.1234567890123456797 UTC". Therefore, DateTime doesn't need zettasecond precision. 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. > [EMAIL PROTECTED] (Rich Bowen) wrote: > > 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". 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. > > Since you have to store, and therefore retrieve and parse, two > > values instead of one, it makes this storage format more > > difficult. > > That's irrelevant when you use a fractional part. No, you can't just store the fractional part in a floating point variable in Perl. Not if you have a precision of a second or better over a long range of dates. You'll have to look at modules like Math::BigFloat; which involves more than one scalar value per number. > > 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 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. (Yes, I know Rich said microseconds. But I can imagine that kind of precisions being important. But you have to draw the line somewhere.) Eugene
