Re: Proposal for a new Temporal time-measurement paradigm
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
Re: Proposal for a new Temporal time-measurement paradigm
Jon Lang wrote: 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.) Yes, and in a middle ground between fiction and modern records that we are reasonably confident about are historical records. For example, such-and-such happened during the wet season in the 14th year of so-and-so's reign. Often-times we don't know exactly when that was, or even if it was a true account, and so using a distinct reference calendar, say so-and-so's reign (actually further qualified), means we have a way of recording exactly what we know without degrading the information by forcing a conversion based on not well known information at the entry stage. 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. Yes, we seem to see eye-to-eye here. 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? There are several variants of this. See also my first reply paragraph about the reign. For example, you could say that such-and-such happened in Summer of 1406, and you want to record it that way because that's exactly what you know the record says, and having to change this to a specific Gregorian month or day would actually be losing information because you would be claiming more detail as being a recorded fact when it actually isn't; so if someone just records in Summer ... then someone looking at it can know better how sure we are or aren't about something. This isn't to say that we couldn't also record July of 1406 as a separate related datum, but then the latter would be explicitly annotated as being a shoehorning guess to make some kinds of operations easier, but the other Summer ... is all that we actually know. Or, say we have a date saying this was at 6:37am on March 1st of 1887; however, we may not know if they are talking about the Julian or the Gregorian calendar, and so we can't just fix the date into one of those calendars; rather we have to fix it to I believe it is either Julian or Gregorian but I don't know which, which is a distinct calendar. Ultimately a system for handling data should be accurate in clarifying what it does or doesn't know, and only claim exactly what it knows and no more. It needs to be able to distinguish knowing for a fact that something occurred at a specific hour and minute of a specific day on a specific calendar, with considering that information to be more of a guess that they aren't so sure about. Then, say if one wants to compile records and solve a problem, they can give greater weight regarding details to the records that claim to be more certain about what they are saying versus those that claim to be guesses. It can be possible to represent degrees of certainty using different calendars. I'm not really talking about significant figures here like with measuring; what I'm talking about goes a lot deeper than that.
Re: Proposal for a new Temporal time-measurement paradigm
I want to clarify that I currently believe that the Perl 6 core should only include temporal roles and *no* temporal classes. So the Perl 6 core could provide, say, 3 roles, Instant, Duration, and Calendar (or use some other name for the last one). It would also provide now(), sleep(), and calendar() routines that have signatures of Instant, Duration, and Calendar, respectively, without necessarily being more specific. And so, what now() returns would then be entirely implementation-defined; all Perl 6 guarantees is that now() would return some object that does Instant but not what class that object is nor what any of its capabilities are. Each Perl 6 implementation would be responsible for bundling at least one non-core module of its own choice that provides a class for each of the 3 core roles, such that now() can return something on that system. Or alternately, now() doesn't actually have to work at all, say if this Perl is to run say on some embedded system all of whose programs don't need a clock, in which case no implementing classes are bundled. The Calendar role would be the role composed by values that you get from introspecting the return value of now() so that you know in a more generic sense what that Instant-doing object is capable of. You could consult calendar() to introspect what classes now() and sleep() use and know about how to interpret them. All details specific to any calendar, including Gregorian, including concepts like seconds or hours or days, should be left out of the core and be provided by separate modules. Said modules can be self-contained, just say using Perl's ordinary numeric and string types for internal representation, and Perl's single core now() routine they can use to determine the current datetime, and the module can introspect its result or calendar() and figure out how to map that to the internal representation or API it wants to use, as well as figure out the proper way to invoke sleep(). -- Darren Duncan Darren Duncan wrote: Jon Lang wrote: 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). I am more on the fence in regards to default implementations of the roles. But I think that all the messy details of particular calendars, such as Gregorian leap seconds and timezones etc, should not be bundled with Perl, and be separate, where users can upgrade them separately independent of Perl as the measurements and political declarations come in. I still suggest just letting Perl itself be minimalist as far as providing classes go, just say have a class representing a Unix et al timestamp that directly corresponds to the implementation's time system, which differs per OS, plus a means for a program to ask what the current OS's calendar is, and then let separately distributed DateTime et al modules examine this and take care of all the mapping. For example, Perl 6 should include the analogy of Perl 5's time but not an analogy to gmtime or localtime; implementing the latter should be left exclusively to separate modules. This fits in with a Perl philosophy of mainly sticking to being grammar and letting CPAN/etc be the language, especially where complexity comes in. It also means that temporal modules can be bundled with Perl, but that is a choice made by the Perl packagers, not the Perl core, same as deciding what templating or networking or database or whatever modules to bundle.
Re: Proposal for a new Temporal time-measurement paradigm
On Sun, Apr 25, 2010 at 00:46, Darren Duncan dar...@darrenduncan.netwrote: All details specific to any calendar, including Gregorian, including concepts like seconds or hours or days, should be left out of the core and be provided by separate modules. Said modules can be self-contained, just say using Perl's ordinary numeric and string types for internal representation, and Perl's single core now() routine they can use to determine the current datetime, and the module can introspect its result or calendar() and figure out how to map that to the internal representation or API it wants to use, as well as figure out the proper way to invoke sleep(). I think you're taking minimalism at least two steps too far; your bikeshed has become too small to contain a bike. A standard library can and should provide reasonable functionality. We _know_ that the North-Western civilizations' common understanding of time (calendars and time-of-day), as defined in various standards, are fundamental to how we handle a lot of programming problems. I don't see any good reason not to provide the basic functionality needed, and especially not when it's already there. -- Jan
Re: Proposal for a new Temporal time-measurement paradigm
Absolutely ridiculous. The Gregorian calendar is in universal use for civil purposes and definitely belongs in the core. On Saturday, April 24, 2010, Darren Duncan dar...@darrenduncan.net wrote: I want to clarify that I currently believe that the Perl 6 core should only include temporal roles and *no* temporal classes. So the Perl 6 core could provide, say, 3 roles, Instant, Duration, and Calendar (or use some other name for the last one). It would also provide now(), sleep(), and calendar() routines that have signatures of Instant, Duration, and Calendar, respectively, without necessarily being more specific. And so, what now() returns would then be entirely implementation-defined; all Perl 6 guarantees is that now() would return some object that does Instant but not what class that object is nor what any of its capabilities are. Each Perl 6 implementation would be responsible for bundling at least one non-core module of its own choice that provides a class for each of the 3 core roles, such that now() can return something on that system. Or alternately, now() doesn't actually have to work at all, say if this Perl is to run say on some embedded system all of whose programs don't need a clock, in which case no implementing classes are bundled. The Calendar role would be the role composed by values that you get from introspecting the return value of now() so that you know in a more generic sense what that Instant-doing object is capable of. You could consult calendar() to introspect what classes now() and sleep() use and know about how to interpret them. All details specific to any calendar, including Gregorian, including concepts like seconds or hours or days, should be left out of the core and be provided by separate modules. Said modules can be self-contained, just say using Perl's ordinary numeric and string types for internal representation, and Perl's single core now() routine they can use to determine the current datetime, and the module can introspect its result or calendar() and figure out how to map that to the internal representation or API it wants to use, as well as figure out the proper way to invoke sleep(). -- Darren Duncan Darren Duncan wrote: Jon Lang wrote: 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). I am more on the fence in regards to default implementations of the roles. But I think that all the messy details of particular calendars, such as Gregorian leap seconds and timezones etc, should not be bundled with Perl, and be separate, where users can upgrade them separately independent of Perl as the measurements and political declarations come in. I still suggest just letting Perl itself be minimalist as far as providing classes go, just say have a class representing a Unix et al timestamp that directly corresponds to the implementation's time system, which differs per OS, plus a means for a program to ask what the current OS's calendar is, and then let separately distributed DateTime et al modules examine this and take care of all the mapping. For example, Perl 6 should include the analogy of Perl 5's time but not an analogy to gmtime or localtime; implementing the latter should be left exclusively to separate modules. This fits in with a Perl philosophy of mainly sticking to being grammar and letting CPAN/etc be the language, especially where complexity comes in. It also means that temporal modules can be bundled with Perl, but that is a choice made by the Perl packagers, not the Perl core, same as deciding what templating or networking or database or whatever modules to bundle. -- Mark J. Reed markjr...@gmail.com
Re: Proposal for a new Temporal time-measurement paradigm
Jan Ingvoldstad wrote: On Sun, Apr 25, 2010 at 00:46, Darren Duncan dar...@darrenduncan.netwrote: All details specific to any calendar, including Gregorian, including concepts like seconds or hours or days, should be left out of the core and be provided by separate modules. Said modules can be self-contained, just say using Perl's ordinary numeric and string types for internal representation, and Perl's single core now() routine they can use to determine the current datetime, and the module can introspect its result or calendar() and figure out how to map that to the internal representation or API it wants to use, as well as figure out the proper way to invoke sleep(). I think you're taking minimalism at least two steps too far; your bikeshed has become too small to contain a bike. A standard library can and should provide reasonable functionality. We _know_ that the North-Western civilizations' common understanding of time (calendars and time-of-day), as defined in various standards, are fundamental to how we handle a lot of programming problems. I don't see any good reason not to provide the basic functionality needed, and especially not when it's already there. Mark J. Reed wrote: Absolutely ridiculous. The Gregorian calendar is in universal use for civil purposes and definitely belongs in the core. Just because things are practically universal or commonly used doesn't necessarily mean they belong in the Perl 6 core. Granted, many things that are commonly used do belong in the Perl 6 core, when they are relatively simple such as basic generic numbers and strings and collections. But the Gregorian calendar and related matters are sufficiently complex that they should be a non-core component, because both they are sufficiently complex and because their definitions change frequently enough over time, and so they should be free to be developed and updated independently of the Perl 6 core. Case in point, see the Perl 5 DateTime module. This module is frequently updated just for reasons of giving it an updated time-zone database or a database of leap-seconds. It is also updated for other reasons. Keeping these details out of the core frees them up to be easier to keep up to date on a schedule independent of the Perl 6 core. If anything, your argument about Gregorian being universal or common should be an argument for Perl packagers to bundle Gregorian-knowledgeable temporal modules, so that users get them by default. But then there would also be a package-managing system for more easily keeping those non-core components updated as new time-zone databases or leap-second measurements are made. My argument still stands; it is better to not have Gregorian et al in the language core, and rather it should be a recommended module for bundlers. -- Darren Duncan
Re: Proposal for a new Temporal time-measurement paradigm
At 21:09 -0700 4/23/10, 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. At 15:46 -0700 4/24/10, Darren Duncan wrote: All details specific to any calendar, including Gregorian, including concepts like seconds or hours or days, should be left out of the core and be provided by separate modules. Said modules can be self-contained, just say using Perl's ordinary numeric and string types for internal representation, and Perl's single core now() routine they can use to determine the current datetime, and the module can introspect its result or calendar() and figure out how to map that to the internal representation or API it wants to use, as well as figure out the proper way to invoke sleep(). At 19:25 -0400 4/24/10, Mark J. Reed wrote: Absolutely ridiculous. The Gregorian calendar is in universal use for civil purposes and definitely belongs in the core. Please accept a plug for Darren. With all of the political and religious problems associated with calendars I would really like to see perl step aside and do ALL of that in modules or perhaps with use of libraries and methods provided by the operating system in which perl is a current process. Atomic seconds per mean solar day is not a constant and might be changed by political action. Mean solar days per year is determined by your God who tells the earth how fast to spin. Ditto for atomic seconds per year. Days in a month is so screwed up that folks argue about age of children when qualifying for benefits. Please just give up and get perl 6 running without trying to lead the world. Make it easy to set up optional schemes as particular users require. Use the epoch as defined in the operating system or, if undefined, use the start of 1970. You could take the instant of perihelion in what Gregorian people think was 1970 years after some important instant. Well, perhaps is was 1969 years if was Roman numeral I. Do everything in a way totally independent of earthly coordinates of the computer in use. But do assume it's motionless with respect to Earth in a 1 g field perhaps at Greenwich UK or Fort Collins CO. Agree on a format for storing fractional atomic seconds. There are proposals for two word integers with one of them being micro or nano seconds and the other seconds. I prefer IEEE floating point with atomic seconds as the unit of measure. That's a bit like MS Excel where days are used for the unit. The Excel scheme is not as clean because it assumes 86400 seconds in a day and it's a day off between what it thinks was Feb 29, 1900 and its epoch at the start of 1900. In any case users need a time value that can be negative or large positive. It's OK to lose precision for time points a long way from the current epoch. Floating point handles that nicely. We really don't care what day of the week the big bang started on but we really would like to use whatever time system is standard to perl. We'd also like to record time differences between collisions in the new CERN accelerator or the arrival times of entangled photons. Easter is the first Sunday after the first full moon after the vernal equinox - - - except. Some pope ordered a calculation of the date for some 3000 years in advance. He blessed the result. So the rule holds except for the mistakes made 1000 years ago. I learned that in 1961 which is the only year of error in my lifetime. Please don't ask perl 6 to pontificate on things like that. -- -- If you are presented a number as a percentage, and you do not clearly understand the numerator and the denominator involved, you are surely being lied to. --
Re: Proposal for a new Temporal time-measurement paradigm
Jon Lang wrote: Why do I find myself thinking of roles and classes here? IMHO, we should have a role that represents abstractly a moment in time. This role should, in and of itself, not be tied to any particular calendar; its purpose is so that one can write functions that make reference to instances in time without locking oneself into a particular labeling scheme. We should also have a series of classes that compose that role, each class representing a different calendar scheme. For perl 6.0.0, only one such class need be defined: the one representing the Gregorian calendar. Later on, modules can be written to provide additional classes representing other calendar schemes. Fine in theory; in practice, the big question is: how much can we get the role to do, within the no calendar preference constraint? And a corollary to this: can we get it to do enough to be worthwhile? 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. 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. Each instant simply says, I am this point on this particular timeline/calendar, and not try to imply that it is anything against any other calendar. For example, each instant is only a datetime in the Gregorian or Julian or Muslim or Jewish or TAI-1958 or TAI-1970s or whatever. This may result in a proliferation of calendars, but that can be blunted somewhat anywhere there are multiple measuring systems that are guaranteed to be commonly-defined. 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. So all Perl 6 really needs to define is: 1. There is an Instant role and a Duration role. 2. A Duration is an amount of time that isn't fixed on a timeline; to get something fixed on a timeline, use a Range of Instant. 3. The system routine now()/etc returns a value of some Instant-composing class. 4. The Instant/Duration roles define functions like these: abs Duration - Duration Duration + Duration - Duration Duration - Duration - Duration Duration abs_diff Duration - Duration Duration * Numeric - Duration Duration / Numeric - Duration Instant - Instant - Duration Instant abs_diff Instant - Duration Instant + Duration - Instant Instant - Duration - Instant 5. There are absolutely no attributes defined by the Instant or Duration roles; attributes are defined entirely by the specific implementing classes, or other roles that they compose which compose Instant or Duration etc. There is no concept of years/days/etc in Instant or Duration. We might be counting time on Mars for example, so no Terra-centricity. So, basically like that. It keeps the core very simple and we avoid most of the bikeshedding seen so far. 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. This brings up a new discussion point though: We should come out with a list of distinct timelines/calendars and canonical names for them with respect to Perl 6. So to at least help those who are trying to use the exact same calendar to recognize that they are doing so. -- Darren Duncan
Re: Proposal for a new Temporal time-measurement paradigm
On Wed, 21 Apr 2010, Mark J. Reed wrote: I recommend not to open this up for 6.0.0 core. Calendar conversion is easy to do in a module, and the Date class has an absolute day count, which is really all you need everything for an intermediate representation. It wouldn't be hard to port Calendrica, for instance. What he said. Perl is all about good Huffman coding. The _vast_ majority people who need to do stuff with dates and datetimes will be dealing with the modern Gregorian calendar. Therefore, having a correct and simple to use implementation of some minimal Gregorian calendar objects in core makes a lot of sense. For folks who need to get fancier, the day count on the Date class will allow simple conversion between calendars, which they can find on CPAN6, along with modules that do more with the Gregorian calendar. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: Proposal for a new Temporal time-measurement paradigm
Minor nit: On Apr 21, 2010, at 04:57 , Richard Hainsworth wrote: If a calendar system, eg., Chinese, Muslim and Jewish, defines days in the same way, eg., starting at midnight and incorporating leap seconds, for a time-zone, then the naming of the days is done by The Jewish, Muslim, and Baha`i (and, technically at least, Christian) religious calendars use sunset as the start of the day. Only Western Christianity and Baha`i use the Gregorian corrections; Orthodox Christianity and the other aforementioned calendars are Julian. (Actually, the Baha`i calendar seems unclear on this; everything I can find suggests that it's still an open issue for them, but for the moment at least it's tied to the Gregorian calendar.) The Jewish calendar doesn't recognize leap seconds; all time measurements are variable, with the day and night separately divided into 12 sha`ot composed of 60 dakot whose lengths vary as the length of the day/night changes throughout the year. Sunrise and sunset are usually defined as when the leading (resp. trailing) edge of the solar disk crosses the horizon. (Some communities use a variation where sunrise is considered to be first light and sunset the end of twilight; *usually* these are taken as the sun being 16° below the eastern horizon and 7.5° below the western. However, there's a lot of variation between communities, and very little of this is fixed; one opinion sets the start of night as 1 1/4 sha`ot *before* sunset!) Islam has some other sticking points in this area: some communities define the start of a new month based on local time, while others base it on observations at Mecca, with the result that the calendar can vary by a day even in the same location. (This got some discussion in the context of Iraqi sectarian violence a few years back.) Additionally, while Jews use a fixed calculation of when the new moon occurs, Muslims still base the start of the month on direct observation of the new moon, so the calendar can again be off by a day. All of which suggests that it may not actually be possible to come up with a mechanism suitable for representing all of these calendars. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part
Re: Proposal for a new Temporal time-measurement paradigm
Why do I find myself thinking of roles and classes here? IMHO, we should have a role that represents abstractly a moment in time. This role should, in and of itself, not be tied to any particular calendar; its purpose is so that one can write functions that make reference to instances in time without locking oneself into a particular labeling scheme. We should also have a series of classes that compose that role, each class representing a different calendar scheme. For perl 6.0.0, only one such class need be defined: the one representing the Gregorian calendar. Later on, modules can be written to provide additional classes representing other calendar schemes. Fine in theory; in practice, the big question is: how much can we get the role to do, within the no calendar preference constraint? And a corollary to this: can we get it to do enough to be worthwhile? -- Jonathan Dataweaver Lang
Proposal for a new Temporal time-measurement paradigm
In reading all of the discussion about Temporal, I have the uneasy feeling that the current development work is falling into the same traps as other languages. It seems to me that the underlying time-measurement paradigm of the developers is too tightly focused on the Christian Gregorian calendar. The following proposal concerns the time-measurement paradigm. It shows how DateTime arithmetic can be done in a unified way taking into account: - different timezones (including leap seconds and daylight savings changes); - different calendars; - different calendar systems. The paradigm does not provide any API (role/class/method name or definitions) since I could imagine a number are possible, including ones close to the DateTime module being developed. It is possible that the developers already implicitly use a time-measurement paradigm like the one suggested here. If this is the case, it would be best to make the paradigm more explicit, perhaps by including the paradigm in the 'semi-internal' section of the Temporal Spec. We start with a stream of Instants - already specified for perl6, in reality seconds from a single epoch. This stream is universal (our universe being the computers on Earth) in that in whatever time zone a person is, there is the same number of seconds from the start of the epoch. (I believe we can ignore relativity at present.) Imagine these Instants as a horizontal axis. Now we need to *name* these Instants in a conventional manner. Over the top of the Instants we have what I am calling a filter, or rather a series of filters. A filter groups the periods in the filter below it into longer periods. Hence, the first filter groups Instants into days. The day filter is like a set of windows over the Instant stream. The first - day - filter is defined for a particular jurisdiction and time zone. Eg there is a filter for the Moscow time zone. Each element - RU-Mos-day - knows its start and finish in terms of Instants. Ordinarily, the number of Instants (seconds) is fixed per day, but from time to time leap seconds are added to a day. Note that in each time zone the leap seconds may be added at different times in the universal Instant stream. That is, normally leap seconds and daylight saving changes are implemented at midnight in each time zone. The implementation of a time-zone filter would be the same for all time zones, namely an iterator that generates a new day as a fixed number of Instants after the start of the previous day, plus a list of exceptions when the *end* of a day is extended/contracted by some number of Instants (due to leap seconds of daylight saving). The difference between time zones would be that the start of the filter (the epoch of the filter) is shifted up or down the Instant stream, and the list of exceptions for time zones/jurisdictions would be different, depending on jurisdiction and daylight saving. It is conventional to refer to days in terms of a calendar system. Calendars introduce a variety of problems. Significant numbers of people on the planet use the Chinese, Muslim, Jewish and Baha'i calendars - all of which are very different in structure. In some countries, two calendar systems are used simultaneously, with people switching between them according to the function of the day. For example, in Russia there are two concurrent calendars (the secular and religious) and they are a fixed number of days apart. Hence Christmas - December 25 in both calendars - occurs on December 25 in the secular calendar, but on Jan 5 (I think) according to the secular calendar, but December 25 according to the religious calendar. For perl6 to be universal, it must be clear how these different calendar systems can be integrated. In principle I think all calendars can be adapted using the same filter technique. The description below is for the Christian Gregorian calendar as applied in many secular jurisdictions. We then consider how to adapt the approach to other calendars. Days have two sorts of name: - Day_of_week, which is a simple modulo 7 of the number of days from the start of the epoch. - Calendar_day, which is the year-month-day format. The day filter, eg., Ru-Mos-Day, provides for an arbritary Instant both a day_of_week name (eg. Monday) and an offset in days from the start of the time-zone's epoch. For each day, the filter provides the start and end positions in Instants. Next layer up is a Month filter. Just as there are leap seconds in days, so too there are leap days in Months. The Month filter keeps track of the start and end of each month in days. Just like the day filter, the month filter provides a Month_of_year name and an offset in Months from the start of the epoch. Each month 'knows' its start and end day. Similarly for the Year filter. Consider filters to be windows over the Instant time stream. Looking up from an Instant, the filters provide names for days, months,
Re: Proposal for a new Temporal time-measurement paradigm
I whole-heartedly agree that we need to make a system independent of any sort of time measurement system. I think the conclusion reached on IRC was that most of the world uses or is at least familiar with the Gregorian system. Now, I can't help but think how we would define an Instant. The best (reasonable) choice is something like TAI or Unix Epoch (I could argue that seconds are not independent, but don't trust me; I'd suggest tapping into the cosmic timeline :) ). I also hope there aren't going to be any leap Instants. (the filter should take care of leaping, after all the calendar has an issue with leaping.) If there isn't a standard defining how many seconds are in a year (i.e. as defined by TAI or the metric system or some other international standard), I propose it'd be about 365.25 Gregorian days (although I'd much prefer an international standard to my Indo-European ways :) ). Overall, I think you have a great idea. As long as the filters are implemented simply, I think it will prove to be the best option. -- Don't Panic!
Re: Proposal for a new Temporal time-measurement paradigm
I recommend not to open this up for 6.0.0 core. Calendar conversion is easy to do in a module, and the Date class has an absolute day count, which is really all you need everything for an intermediate representation. It wouldn't be hard to port Calendrica, for instance. Also, the difference between the secular and religious calendars in Russia is not fixed. It's currently 13 days, but only since 1900, before which it was 12 days, and after 2100 it will be 14 days. Calendar conversion can be tricky - which is another reason to leave it out of core. IMO. On Wednesday, April 21, 2010, Matthew rnd...@gmail.com wrote: I whole-heartedly agree that we need to make a system independent of any sort of time measurement system. I think the conclusion reached on IRC was that most of the world uses or is at least familiar with the Gregorian system. Now, I can't help but think how we would define an Instant. The best (reasonable) choice is something like TAI or Unix Epoch (I could argue that seconds are not independent, but don't trust me; I'd suggest tapping into the cosmic timeline :) ). I also hope there aren't going to be any leap Instants. (the filter should take care of leaping, after all the calendar has an issue with leaping.) If there isn't a standard defining how many seconds are in a year (i.e. as defined by TAI or the metric system or some other international standard), I propose it'd be about 365.25 Gregorian days (although I'd much prefer an international standard to my Indo-European ways :) ). Overall, I think you have a great idea. As long as the filters are implemented simply, I think it will prove to be the best option. -- Don't Panic! -- Mark J. Reed markjr...@gmail.com
