Darren Duncan wrote: > I think that the most thorough solution is to just take it for granted that > there are multiple reference timelines/calendars and that in general it is > impossible to reconcile them with each other.
Taking this to its logical extreme, there might be a few (admittedly fringe) cases where someone might want a calendar that, even in principle, cannot be reconciled with anything else: consider someone who's writing an application that tracks events in a fantasy setting, such as the Lord of the Rings or the Wheel of Time. (Something like this actually occurred with a friend of mine, who's hobby is pen-and-paper roleplaying games; he wanted to build a database to track the events in his campaign, but ran into the problem that nothing allowed for the creation of a custom calendar such as the one in his fictional setting.) > And so, what we can do in general is simply have an Instant role and a > Duration role, and pairs of types where each member composes one of those, > and then all that needs to exist for temporal routines is an independent > collection for each pair that is closed within that pair. This is what I was trying to say. And where you _can_ convert between calendars, you can always write a "type-casting" routine that takes, say, a Julian Instant as an input and produces a Gregorian Instant as the output. Incidently, it might be possible for two calendar systems to share the same Duration implementation; IIRC, the Julian and Gregorian calendars both use the same concept of seconds, minutes, hours, etc. Likewise, a calendar system might end up with more than one type of Duration: it's always possible to convert between seconds, minutes, hours, days, and weeks; and its also always possible to convert between months, years, decades, centuries, and millenia; but it isn't always so easy to convert between days and years. I could see the Gregorian implementation having two kinds of Durations: short Durations that deal with everything from seconds to weeks, and long Durations that deal with everything from months to millennia. > Similarly, there would be a calendar for "I don't know what calendar", or > varying degrees of such, which is often the case for dated historical > records. With this, I'm not quite following you. Could you give an example of what you mean? > What calendars/timelines are supported can be implementation-defined and/or > provided by modules. Each Perl 6 implementation can be minimalist as far as > composing classes go; just provide some programmatically readable way to > discover what calendar the system uses so then modules can use that to > decide how to make a particular calendar work on any system as possible. We _should_ define a "default calendar", which is the one that Perl uses when returning values from now(), etc. That is, Perl 6.0.0 should define the Instant and Duration roles as you outlined above, plus a set of classes that implement those roles according to the Gregorian calendar system. If you want to replace that with another calendar system in your implementation of Perl, the language already has the means of allowing you to do so (e.g., replacing &now with a variant that returns a different type of Instant). -- Jonathan "Dataweaver" Lang
