On Sun, 6 May 2001 03:35:15 +0530, Abhijit Menon-Sen said:
> On 2001-05-05 13:09:18, [EMAIL PROTECTED] wrote:
> >
> > In all of the various date formats I have looked at, each one has
> > certain flaws.
>
> 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?
> > ISO requires that you know a week number, and nobody thinks like that.
>
> ISO 8601 <URL:http://www.iso.ch/markete/8601.pdf> permits you to use
> week and day numbers, but you are by no means required to do so. The
> most commonly used representation looks like "CCYYMMDDTHHMMSSZ", and
> there are relatively sane reduced-accuracy representations, extensions
> to specify periods of time, etc.
>
> Markus Kuhn's <http://www.cl.cam.ac.uk/~mgk25/iso-time.html> is a very
> useful overview of the standard (which is unfortunately ambiguous in
> several places).
It's this ambiguity, and the fact that an ISO date can be expressed 6 different
ways, which makes ISO less attractive to me.
> > Expressing the date and the time as separate fields is too much work
> > to convert back to something useful.
>
> I'm not sure what you mean.
What I means is that some time formats require that the time and the date be
stored as separate fields. Julian dates, for example, require that you store
the time as a separate field, because the julian date expresses only the date.
Since you have to store, and therefore retrieve and parse, two values instead
of one, it makes this storage format more difficult. I'm primarily interested
in a storable value that you can put in a database, rather than a struct that
you can hold in memory.
> > And then I encountered ICal format.
>
> ICal appears to use a subset of the ISO 8601 format (RFC 2445, sections
> #4.3.{4,5,6,9,12}).
Indeed.
> > 1) A Date::Foo object will *always* have an internal representaton as
> > an ICal string, no matter what you provide it when you create it.
>
> ICal does not permit sub-second precision, so you would lose information
> when converting from formats which do. There are few practical uses for
> TAI64NA's attosecond precision, but milli- and microsecond precision is
> much more common in existing data.
While I've read this various places, I've never encountered a real application
where microsecond precision was necessary in a calendaring context. Is this a
real concern? (I'm really asking. This seems utterly unimportant to me, but I
would not want to build a system that was useless to a large number of people
because of overlooking attosecond accuracy.)
> > The consequence of this, if we're careful, is that we can create a
> > Date::Discordian object, for example, and then rebless it into the
> > Date::Mayan class, and it would just work:
> >
> > my $disco = Date::Discordian->new( disco => '23 Chaos, YOLD 3177');
> > bless $disco, 'Date::Mayan';
> > print $disco->mayan;
>
> Something which avoided the re-blessing would be less fragile:
>
> my $disco = Date::Discordian->new(disco => '23 Chaos, YOLD 3177');
> my $mdisco = Date::Mayan->new($disco);
> print $mdisco->as_string; # or whatever.
Not sure what you mean by "less fragile." However, I can see that this might be
cool - if you pass in something that is obviously an object, we can just call
the ical method on it for a starting point.
--
Rich Bowen - [EMAIL PROTECTED]
ReefKnot - http://www.reefknot.org
