=pod =encoding utf8 =head1 NAME Muldis::D::Ext::Temporal - Muldis D extension for temporal data types and operators =head1 VERSION This document is Muldis::D::Ext::Temporal version 0.80.0. =head1 PREFACE This document is part of the Muldis D language specification, whose root document is L; you should read that root document before you read this one, which provides subservient details. =head1 DESCRIPTION Muldis D has a mandatory core set of system-defined (eternally available) entities, which is referred to as the I or the I; they are the minimal entities that all Muldis D implementations need to provide; they are mutually self-describing and are used to bootstrap the language; any entities outside the core, called I, are non-mandatory and are defined in terms of the core or each other, but the reverse isn't true. This current C document describes the system-defined I, which consists of temporal data types and operators, particularly calendar dates and intervals. The bundled data types describe common kinds of temporal artifacts according to modern calendars. They can represent a variety of precisions and epochs so that users can employ them in a way that most accurately represents what they actually know about their data. The C document also provides a selection of operators for working with the C and C types that are part of the Muldis D language core. The I is expressly not meant to be complete by any means, as a solution for working with temporal data. Rather it is meant to be "good enough" for many common uses. Moreover it isn't intended to have a scope much greater than the temporal data handling abilities of the ISO/IEC 9075 (SQL) standard and the Perl L module. In many situations, users may be better off ignoring this extension, and using Muldis D's core facilities for user-defined types and routines, and code an alternate temporal data solution that works best for them, building over Muldis D's basic integer or such types, or alternately using third-party Muldis D temporal extensions. This current extension exists primarily to ease the porting of SQL databases to Muldis D, and save users accustomed to SQL's facilities and the Perl DateTime module's facilities from having to frequently reinvent the wheel. The details of this Muldis D extension are typically just the same as those in ISO/IEC 9075 (SQL) section "4.6 Datetimes and intervals", but with some alterations. As with SQL and DateTime, dates and times are specified as YYYY.MM.DD.HH.II.SS+ in the proleptic Gregorian calendar, specifically the version with a year zero and negative year numbers, either in the UTC time-zone or floating / no-zone. Matters of "local time" or specifications of other time-zones or daylight savings time are not supported for encoding into values, due partly to various logical problems and complexity such as an inability to distinguish between duplicated times of day around a daylight savings adjustment. If you want to work with "local time", you generally will have to convert to UTC on input and from UTC on output with the I; UTC is better for storage, local is maybe better for display. Now the general practice of working with calendar-centric temporal data is an imperfect process and can not be done with perfect mathematical precision. This is partly because our temporal data in general comes from measurements of environmental cycles (such as rotations of the Earth, revolutions of the Earth's moon around it, and revolutions of the Earth around its sun), which not only are rounded approximations, but we also know for a fact that the actual amount of time these events takes slowly varies over time (such as that the rotation of the Earth is gradually slowing as the moon gradually drifts away from it each year). Also our typical calendaring systems change over time, sometimes to deal with our improved ability to measure the environmental cycles or compensate for drift; witness for example a large part of the world's moving from the Julian to the Gregorian calendar. So the best we have to work with in general will involve rounding, and sometimes a conceptually commutative or associative sequence of operations on temporal data may not yield an identical result from identical inputs when the operations are rearranged into a conceptually equivalent but different form; a simple example being adding or subtracting dates. All the issues can be complicated. This current document does not describe the polymorphic operators that all types, or some types including core types, have defined over them; said operators are defined once for all types in L. I =head1 TYPE SUMMARY Following are all the data types described in this document, arranged in a type graph according to their proper sub|supertype relationships (but that the first 3 just reappear from the core set to provide a similar context, and aren't re-described here): sys.std.Core.Type.Universal sys.std.Core.Type.Empty sys.std.Core.Type.Scalar sys.std.Core.Type.DHScalar # The following are all regular ordered scalar types. sys.std.Temporal.Type.UTCInstant sys.std.Temporal.Type.UTCDateTime sys.std.Temporal.Type.UTCDate sys.std.Temporal.Type.UTCTime sys.std.Temporal.Type.FloatInstant sys.std.Temporal.Type.FloatDateTime sys.std.Temporal.Type.FloatDate sys.std.Temporal.Type.FloatTime sys.std.Temporal.Type.UTCDuration sys.std.Core.Type.Int sys.std.Core.Type.NNInt sys.std.Core.Type.PInt # These are all finite positive integer types. sys.std.Temporal.Type.PInt[12|31] # These are all finite non-negative integer types. sys.std.Temporal.Type.NNInt[23|59] sys.std.Core.Type.Rat sys.std.Core.Type.NNRat # These are all infinite non-neg rational types. sys.std.Temporal.Type.NNRatLT62 I =head1 SYSTEM-DEFINED TEMPORAL-CONCERNING DATA TYPES These non-core data types are all ordered scalar types. =head2 sys.std.Temporal.Type.PInt[12|31] This is an enumeration data type. C is a proper subtype of C where all member values are not greater than 12|31. Its default and minimum value is 1; its maximum value is 12|31. The significance is that in proleptic Gregorian dates, the [month|month-day] portion is a positive integer not greater than 12|31. =head2 sys.std.Temporal.Type.NNInt[23|59] This is an enumeration data type. C is a proper subtype of C where all member values are not greater than 23|59. Its default and minimum value is 0; its maximum value is 23|59. The significance is that in the time portion of proleptic Gregorian dates, the [hour|minute] portion is a non-negative integer not greater than 23|59. =head2 sys.std.Temporal.Type.NNRatLT62 This is an enumeration data type. C is a proper subtype of C where all member values are less than 62. Its default and minimum value is 0; its maximum value is conceptually infinitessimally less than 62 and practically impossible. The significance is that in the time portion of proleptic Gregorian dates, the 'second' portion is a non-negative rational less than 62. The cardinality of this type is infinity; to define a most-generalized finite C subtype, you must specify the greatest magnitude value denominator of its C possrep, that is, its maximum precision (that denominator is 10^9 if we're working to nanosecond precision). =head2 sys.std.Temporal.Type.UTCInstant This is a structure data type. A C is a single point in time, or a periodic multiplicity of points in time, which is specified with arbitrary precision using a set of unit quantities involving multiple units, where the units do not generally have a fixed conversion rate with each other. A C is defined against the proleptic Gregorian calendar and uses these 6 units: terrestrial year, month within year, day within month, hour within day, minute within hour, second and possibly fraction of a second within minute; the only fixed conversion rates are: 1 year is 12 months, 1 hour is 60 minutes. A C is defined against the UTC time-zone specifically, so you use it when you I that the instant you are specifying was experienced in the UTC time-zone with the specified unit values; if you are otherwise working according to your local time-zone, you would be selecting your C values in terms of a time-zone offset (and daylight-savings time offset if applicable) from your local time. A C has 1 system-defined possrep whose name is C, which has 6 attributes: C (a C), C (a C), C (a C), C (a C), C (a C), C (a C). For each attribute, that attribute should be a C if a quanity in that unit is known, and it should be C if there is no applicable or known quantity in that unit. The C values greater than zero are CE, those less than zero are BCE. The C value C<1> corresponds to the month of January, and C<12> corresponds to the month of December. The value of C is further restricted depending on the combined values of C and C, such that all 3 together may only represent a valid date of the proleptic Gregorian calendar (taking into account leap-days); so for example you can't select April 31st or February 30th. The value of C is further restricted as per C, as leap-seconds are only valid on certain days, and perhaps only when the hour-minute is 23-59. These further restrictions do not apply if any of the attributes needed to calculate whether they apply are C. The default value of C is exactly midnight at the start of January 1st of the year 1 CE (which also happens to be the proleptic Gregorian calendar's epoch); its minimum and maximum values are conceptually infinities and practically impossible. The cardinality of this type is infinity; to define a most-generalized finite C subtype, you must specify the earliest and latest dates it includes (minimally, the earliest and latest C), as well as the granularity of the type as a fraction of a second (minimally, the largest value denominator for C). The C type has a default ordering algorithm; for 2 distinct C values, the earlier value is ordered before the later value. To make full ordering of C values possible and deterministic (though semi-meaningless) in the face of unknown/inapplicable attributes; the algorithm works like this: 1. ordering is done numerically one attribute at a time, from the largest units to the smallest; 2. for each attribute, the C value will order before any C value. =head2 sys.std.Temporal.Type.UTCDateTime This is an enumeration data type. A C is a single specific time on a specific date, with precision to arbitrary fractions of a second. A C is a proper subtype of C where all 6 attributes of its C possrep have C / known values. A C adds 1 system-defined possrep whose name is C, which has 6 attributes: C (an C), C (a C), C (a C), C (a C), C (a C), C (a C). The default and minimum and maximum values are the same as for C. =head2 sys.std.Temporal.Type.UTCDate This is an enumeration data type. A C is a single specific terrestrial day, at no particular time of day. A C is a proper subtype of C where the 3 attributes of its C possrep named [C, C, C] have C / known values, and the other 3 C possrep attributes each have the C / unknown value. A C adds 1 system-defined possrep whose name is C, which has 3 attributes: C (an C), C (a C), C (a C). The default value of C is January 1st of the year 1 CE; its minimum and maximum values are conceptually infinities and practically impossible. The cardinality of this type is infinity; to define a most-generalized finite C subtype, you must specify the earliest and latest dates it includes (minimally, the earliest and latest C). =head2 sys.std.Temporal.Type.UTCTime This is an enumeration data type. A C is a single specific time that isn't on any day in particular (or alternately that is repeating on multiple days), with a precision to arbitrary fractions of a second; its allowed range is between zero seconds (inclusive) and 1 terrestrial day (exclusive). A C is a proper subtype of C where the 3 attributes of its C possrep named [C, C, C] have C / known values, and the other 3 C possrep attributes each have the C / unknown value. A C adds 1 system-defined possrep whose name is C