__________________________________________________
__________________________________________________

CoreDate
Contents Of This Document

I do attest that the CoreDate protocol is entirely my intellectual property. I do hereby offer this protocol as a gift for public use free and clear of copyright and without reservation, requirement, or encumberance of any kind so that it may be used, copied, and distributed by anyone and by everyone and for any purpose.

The gift of this protocol is specific and does not include any other intellectual property. I do retain the copyright to all else unless specifically and explicitly stated otherwise.

John Ragan
3 February 2007
Member, Internet Technical Committee

( The gift is certainly given, but the customary attribution would be appreciated.)

( Comments: Technical suggestions and comments should be sent to john in this domain with CoreDate as the subject. They will be considered with appreciation.)

The protocol is designed for the universal expression of temporal values that are easily red and understood by people and by systems. A coredate value object is a structured string of digits that is easier to read and understand than any prior date-time protocol. But the rigorous presentation of the protocol makes it seem complex.

Objectives:
      Create a standardized form for temporal value
          expression and
          communication.
      Simplify date programming.
      Create logical date expression.
      Improve logic embedded in dates.
      Ease reading and comprehending dates.
      Enable the definition of many temporal domains.
      Enable a framework for universal domain relations.

Secondary Objectives:
      Security support in processing and communication.
      Speed in processing.
      Ease understanding by speakers of various languages.

Not Objectives:
      Replacement of the general public's date-time protocols.
      A time-keeper.
      Any horological mechanism for generating data.
      Date or time calculation.

Possible Future:
      Find a way to cleanse and clarify the legacy component
          concepts that the protocol concept must use.

Development History:
      The protocol was initially developed for systems.
      It was made to also be quickly and easily red by people.
      Short forms were later added for people.
      The structure was expanded to support multiple
          independent temporal domains while embracing
          all within a manageable universal concept domain.

-- --

( I built the old standard form into systems for years, so this was overlooked when it was made public. My apology, if you please, but it needed correction. )

-- release history --

The Release History appendix shows previously published protocol releases.

-- reference date --

Please cite a publication date of

-- definition of release concept --

Definition of Release :
      A release identifies a published change in the protocol.
      It identifies that publication object.
      A release identifier is a six-digit number.
      Release identifiers are sequential.
      They are not necessarily consecutive.
      Release identifiers are derived from dates.
      They usually coincide with the date of publication,
          but are not required to do so.
      Digit quantity is set to support a century of legacy systems.

Version Numbers :
      CoreDate does not use version numbers.

( The coredate protocol began development in the early nineties, and has been used by its creator in system development and communication since then.)

The attempt to construct a precise, coherent, and useful date-time protocol encountered intractable problems, some of which may be insurmountable. Those problems are not of CoreDate origin, but are found within the time and date concepts that we take for granted in the sloppiness of our daily activities. Although they are hidden, they can be seen if one looks closely at the various concepts and protocols embedded in the ordinary

However, as shown in the Intractable Problems appendix, they will not be allowed to thwart CoreDate's progress.

( The protocol begins here. )

__________________________________________________
__________________________________________________
CoreDate
Protocol

_________________________
CoreDate
Protocol
Section
Basic Specifications
And Definitions

-- . --

-- introduction --

This is the specification for the expression and communication of temporal values. A value which complies with this specification may be generically described as a coredate, this specification will be identified as the CoreDate protocol, and the concept will be identified as CoreDate.

A coredate is a unit instance expression or communication of a specific temporal position. It may be referred to as a value or as an object. It includes both a date and a time in the value. As the specification of a temporal position, the terms "date" and "time" are not necessary and are used here for clarity at inception; it is simply a coredate.

It might help the beginner to realize that we are dealing only with time. Date is merely a description of certain units of time. The old "date" concept is used to provide a bridge from the old concepts into the CoreDate. Most CoreDate values contain both date units and time units to specify a time.

The protocol is irrespective of the current technology, science, and philosophy. The protocol recognizes the fact that the subject is approximate and philosophical and that those factors must be ignored in daily affairs and operational systems. The expression of a coredate is always an absolute value; i.e., it is a given without debate except, perhaps, in matters of accuracy.

( If you wish, you can find a discussion of the fundamental physics and philosophy of time in the "Nature Of Time" in the theory document, and a discussion of time problems in the Intractable Problems appendix.)

-- . --

-- characters --

This presents the characters that may be used in a coredate value string. ( Excluded from this discussion of characters are time zones and environment codes that are discussed in detail elsewhere.)

( A secondary purpose of the character specification is system security support.)

Every character in a coredate value is an Arabic digit. (Except for an expressed redirector that is discussed below.)

All characters in the coredate are significant. Some may be zero, but no character position may be blank and none may be null. All characters contribute to the expression and(or) designation of a temporal instance. Where a value is required, but unknown, all of its characters will be zeros.

Separators and delimiters are not permitted; e.g., commas, periods, colons, etc.

Descriptive text and flags are not permitted; e.g., AM, PM, BC, eastern standard, etc.

-- . --

-- precision --

Value lengths are specific for the coredate forms and cannot be truncated.

If a value's required precision exceeds the expresser's precision ability, the value will be filled from the right side with zeros. For example, if the application requires an extended standard value, but the expresser is accurate only to the second, the value will be right-filled with zeros for all decimal positions.

( Without a null value, a precision is always implied that may frequently be unrealistic. However, that same extraordinary precision is implied but unsaid throughout human endeavors, and is only manifested in the CoreDate protocol's cleanliness.)

-- . --

-- form lengths --

The entire coredate value concept consists of twenty-one (21) single-character positions. Various coredate forms are created by using substrings of those characters. Only the specified forms are recognized.

( A secondary purpose of the form length specification is system security support.)

The coredate value string may be presented in various controlled forms, of which the length is critically important. The protocol will fail if the length specifications are not observed. ( The form lengths discussion is valid after stripping optional environment codes and time zones from values. )

A coredate may be presented with or without comment in any of the following specified forms. The receiving system or person will recognize it in context without comment.

A coredate value (object) has one of the following lengths. The length is the number of characters in the string.
      14 :   Standard coredates have fourteen characters.
                Character positions one through fourteen.
      16 :   Plus coredates have sixteen characters.
                Character positions one through sixteen.
      21 :   Extended coredates have twenty one characters.
                Character positions one through twenty one.
      Abbreviated forms:
      8 :     Short dates are eight characters starting at one.
      4 :     Short times are four characters starting at nine.

Abbreviated forms :
      The two abbreviated forms are designed to ease usage by
          people, so they deviate from the main forms in that:
      They do not support the redirector.
      They are not concatenated by the protocol.
      They do not support time zones.
      They do not support environment codes.
      Where a short form will not suffice, the standard,
          plus, or extended form must be used.

-- . --

-- value positioning --

All environments use the same method of relative value positioning within the coredate object.

It follows the numeric convention with the largest on the left and decrementation to the right.

The locally recognized most prominent cycles are in the leftmost positions, with diminutive values on the right.

-- . --

-- metadata --

Metadata is embedded in the protocol's form construct, so all metadata is always implicitly conveyed with coredate values.

Explicit metadata, labels, and tags will never be embedded in, appended to, or prefix a coredate, and will not accompany a coredate that is contextually recognizable as a coredate object.

Systems and people will recognize any coredate value that is encountered in context.

The exercise of any protocol option(s) will be apparent.

-- . --

-- redirector --

The redirector specifies the direction of the value.

When used, the redirector replaces the final digit.

The redirector character is a minus symbol; ASCII character 45. The absence of the redirector implies a positive value.

The redirector specifies that the value is before the environment's defined zero date.

The redirector makes the value negative; i.e., before zero.

The redirector is not used with short form values.

-- . --

-- temporal environments --

Disparate independent temporal environments are supported.

Each environment is identified by a unique short code.

The environment code usage is optional, and is decided for each coredate object. It is prepended to the coredate object.

Environment codes are designed for recognition by unattended or autonomous systems as well as by people.

See the Temporal Environments section.

-- . --

-- time zones --

Time zones are supported.

Time zone usage is optional, and is decided for each coredate object. It is apppended to the coredate object.

Time zones are designed for recognition by unattended or autonomous systems as well as by people.

See the Time Zone Option section.

-- . --

-- anomaly correction --

Implicit in the value of a coredate object is always the assumption that a value includes published anomaly adjustments that are made before specification of the value; e.g., leap year, leap seconds, etc. (See the previous comment on technology, science, and philosophy).

-- . --

-- universal base --

The base for the universal CoreDate environment is the start of the primary Terra (Earth) environment, which uses the Gregorian calendar.

Every CoreDate environment's start date will be synchronized with the universal base start date; i.e., the zero value of each will be calculated and positioned to force occurrance simultaneity of the zero value with the universal zero value.

See the Temporal Environments section.

See the Synchronization Protocol appendix.

( For system developers :
      A coredate value that is all zeros is positive and is AD. That is logically possible since we assume that the zero value includes an infinitude of microscopic non-zero values that human abilities can never segregate, and we have arbitrarily chosen the positive side. That may seem silly only if you are not a system developer who has had to wrestle with such things in other time protocols.)

-- . --

-- value string presentation --

Value strings will always present the prescribed characters. A coredate value cannot be communicated in a tokenized, translated, compressed, encrypted, or abbreviated form except as part of a tokenized, translated, compressed, or encrypted document or transmission. (CoreDate is designed to simultaneously support security, recognition by people, and processing by autonomous systems.)

_________________________
CoreDate
Protocol
Section
Environment Example
TER Environment

-- . --

-- note --

( As an example, this section logically seems to belong in an appendix, and certainly not within the protocol. However, it is too important during inception to be moved out of the way, and is placed here so people will stumble over it. )

-- . --

-- purpose --

This section offers some basic examples of an environment definition. It defines the primary temporal environment for this planet, which it identifies as TER for Terra. Existing authorities will be recognized, but subsumed by the CoreDate protocol.

( See the Temporal Environments section for the general environment specification for all environments. This section is intended to be an example. )

-- . --

-- authority --

Because the protocol is still within its inception period, this site will retain the TER environment option under consideration until the protocol is stabilized and until further notice.

Therefore, this may be viewed as interim until the environment is handed to a valid and adequate defining authority. That is not expected to present a problem because :
      The civilization has a primitive operational environment.
      And because the protocol is being developed in a manner that will allow systems to orthogonally project that primitive environment into CoreDate to immediately begin benefiting from the protocol.

( If you might be interested in assuming the responsibility at a future date, send a communication to john in this domain with "coredate" in the subject area.)

-- . --

-- existing authorities --

Existing authorities are hereby recognized except where they conflict with CoreDate. They are subsumed by the CoreDate protocol.

-- . --

-- environment identification --

      Identifier : TER
      Description : Planet Earth, or Terra.
      Physical locale : The planet.
      Earth's temporal environment code is TER.
      TER is the primary environment of the planet.

-- . --

-- unit basis --

This environment follows the Gregorian calendar.

The zero date is set by the Gregorian calendar.

( Additional specific coverage may be added later.)

-- . --

-- time zones --

The environment will use time zones. The existing time zones will be used.

-- . --

-- coredate forms --

All of the specified forms will be fully supported as defined.

-- . --

-- value ranges --

For the primary TER temporal environment, this addresses the value range of each component of the coredate value string.

The locations of these values in the coredate string are shown in the following Table Of Value Strings.

The first four digits of the string are the year. Each of them has the full range of zero through nine.

Locations 5 and 6 are the month values. Location 5 has a range of zero through one. Location 6 has a range of zero through nine.

Locations 7 and 8 are day values. Location 7 has a range of zero through three. Location 8 has a range of zero through nine.

Locations 9 and 10 are hour values. Location 9 has a range of zero through two. Location 10 has a range of zero through four. (Those specifications thereby also specify the use of the twenty four (24) hour clock, which meets the specification requiring the absence of text.)

Locations 11 and 12 are minute values. Location 11 has a range of zero through five. Location 12 has a range of zero through nine.

Locations 13 and 14 are second values. Location 13 has a range of zero through five. Location 14 has a range of zero through nine.

Locations 15 through 21 are fractional parts of a second. They each have a range of zero through nine.

-- . --

-- Table Of Value Strings --
Terra Environment

-- . --

-- examples --

A symbolic representation:
      YYYYMMDDHHMMSSNNNNNNN

Example :
      20100124102304 or
      2010012410230400 or
      201001241023040062384
Usually red as January twenty-fourth of 2010 at 10 23 04 AM or perhaps as 24 January 10, 10 23 04 AM.

Example:
      9010000000000-
Usually red as nine thousand and ten BC.

Example:
      20170111
Usually red as the eleventh of January of 2017.

Example:
      1304
Usually red as thirteen oh four,
or maybe as four minutes after one PM.

-- --

_________________________
CoreDate
Protocol
Section
Time Zones
General Specification

-- . --

-- introduction --

Time zones are divisions of a temporal environment that are designed to make possible the statement of meaningful local times anywhere in a temporal environment while maintaining the unified temporal integrity of the environment with offset adjustments.

The environment's defining authority will explicitly direct their use if they are found to be needed. Time zone quantities, identifiers, offset adjustments, and other attributes will be entirely specified by each defining authority without respect to other environments.

An environment that is divided by time zones will be synchronized by its first, or prime, zone unless otherwise explicitly stated by its defining authority in its defining document.

-- . --

-- geometry --

Geometry of time zones is entirely at the discretion of the defining authority.

An environment's time zone geometries are not required to be universally recognizable. The zones' shapes, sizes, and positions will not necessarilly be identical or reqular. It is possible that some will not even be cyclically recognizable.

However, the zone geometries are subject to the publication requirements that must be met by the environment authority.

-- . --

-- usage --

Time zone usage with a coredate is optional. A transmitter of a coredate will include a time zone with the value as needed and at his discretion.

When used, the properly delimited time zone is appended to the coredate value string.

Delimiters:
      The identifier will be prefixed by the ASCII character 60, a less-than symbol (<).
      The character 62, a greater-than symbol (>), will be appended to the identifer.
      The identifier is thus delimited and enveloped by those symbols.

Other characters, blanks, and nulls are not permitted within or before the time zone envelope, and are not permitted within or before the identifier.

A time zone in a coredate string does not modify the previous character functions and behaviors. Specifically, the redirector character position and function remain the same.

In a situation where a time zone is required, but the zone is unknown, the time zone may be expressed as 00. That may also be used to make explicit the fact that a coredate may or may not be of the local or any other time zone.

-- . --

-- examples --

A symbolic representation:
      YYYYMMDDHHMMSSNNNNNNN<ZZ>

Example:
      20100124102304<06>
      2010012410230400<06>
      201001241023040062384<06>
In both cases, the previously given examples have now been re-specified within time zone number six. Note that usage is eased for people and for systems. In processing, a system can easily validate the value length independently of the time zone's arbitrary size.

_________________________
CoreDate
Protocol
Section
Temporal Environments
General Specification

-- . --

-- the subject domain --

A CoreDate temporal environment is one that requires an in-context specification of the character attributes of the protocol to maintain local date-time validity and viability. It is any location that can be located, delimited, and defined, for which a horological mechanism can be established, and for which a logical, consistent, and coherent date sequence can be established, defined, and published.

Although a temporal environment may include the same or part of the same geographical or spatial location that is included by another environment, it may not be defined in terms of another environment or environments. Its definition must be able to stand alone. The exception is its zero value which must coincide with that of all existing environments.

A location may require and have multiple independent definitions. For example, in addition to its primary definition, earth might have a defined environment for use by such activities as paleontology and geology that need to use geologically significant temporal expanses. Such activities as cosmology and astrophysics might require definitions of slightly differing universal locales.

Only God cannot have a temporal environment because he IS, subsuming all else, as illustrated by Godel's incompleteness theorem. All else is temporally definable.

( Although the intellectual pull might be strong, and the subject may appear to be simple, it is strongly recommended that astronomical environment definitions include the participation of astronomers, and that universal definitions include theoretical physicists and, perhaps, a philosopher or two. There are problems involved that may not be solvable within our current level of philosophical immaturity.)

-- . --

-- coredate community --

The CoreDate community, which is referenced below, consists of all environment defining authorities.

-- . --

-- defining authority --

Duties :
      A defining authority takes responsibility for creating, publishing, and maintaning a temporal environment definition that meets the CoreDate definition requirements.
      An environment's defining authority will erect, provision, and maintain a publicly available internet server for its environment.

Recognition :
      If an aspirant
          identifies itself as such,
          publishes its environment definition proposal,
          brings its server on line, and
          receives no public challenge within ninety earth days
          after completing those tasks,
          then it will be recognized as a defining authority.
      Publication will include distribution of all required documents
          with the publication date and the address of its complete
          and functioning server to all of the CoreDate community's
          authorities.
      Publication will be in Standard American English. Copies in
          other languages may accompany it, but those copies will
          be considered protocol-superfluous and non-canonical.
      It will subsequently notify all authorities immediately after
          completing its required ninety day waiting period
          without challenge.
      A challenge by email must be copied to the community
          by the sender.
      A challenge must be boldly identified thereon as such.
      A legitimate challenge must be satisfied by the aspirant.
      ( Acknowledgements by email may be appropriate.)

Amendments :
      An authority may amend its definition at any time.
      Such amendment will be distributed to all CoreDate
          community authorities as a dated proposal.
      The dated proposal will be posted on the server.
      Unless challenged, altered, or withdrawn by announcement,
          the amendment will take effect ninety earth days after
          announcement, whereupon the server will be updated.

Failure :
      Failure to meet or maintain authority requirements will disolve recognition of the authority and its environment.

Transfer :
      That in which, or those in whom are vested the authority may
          transfer it at any time.
      Transfer must include notification of the community by
          both parties including the new functioning server
          address.
      Transfer will take effect ninety days thereafter if no
          challenge is made.
      The new aspirant will complete the transfer by notifying the
          community of completion of the ninety day waiting period.

-- . --

-- standard base --

In matters not specified for an environment, the environment's specification will be that of the Terran environment.

The primary Terran CoreDate standard is Gregorian.

Every temporal environment's start date will be synchronized with the universal start date; i.e., the zero value of each will be calculated and positioned to force occurrance simultaneity with the Terran zero value. Ergo, all environments can be synchronized at will regardless of the degree of complexity of the CoreDate's universal domain.)

See also the Synchronization Protocol appendix.

-- . --

-- unit basis --

The defining authority will explictly specify the environment's unit basis (or basses).

Unit basses may be natural and(or) artificial.

See the Unit Basis) section.

-- . --

-- conversion formulae --

An environment definition must include formulae to convert its values to and from any prime Terran coredate.

It may also include other conversion formulae.

When another authority is unable to use that information to calculate the conversion to its values, it may request assistance from the defining authority.

( Consider this requirement carefully if you have never written a date program. A most colorful environment was an old mainframe department when a frustrated programmer was writing a date converter or calculater.)

-- . --

-- environment server functions --

The server will:
      Serve all environments.
      Serve publicly without cost, demand, or advertisement.
      Maintain the entire definition of its environment including
          the last release or version number.
      Provide the required conversion formulae.
      Show the date of first successful publication and successful
          expiration date of the ninety day waiting period.
      Provide a complete copy with release number of the
          CoreDate protocol version with which it currently
          complies.
      Provide the current local coredate for people in the
          extended coredate format and in the short formats,
          with a statement of accuracy.
      Provide automated (autonomous) service for inter-system
          synchronization requests.
      Provide and maintain a complete list of the CoreDate
          community's server addresses with brief environment
          descriptions.
      Provide the authority's mailing address and contact
          information.
      Provide such other information and services as the authority.
          thinks necessary and(or) appropriate.

-- . --

-- protocol universalization --

( This may be a sensitive matter for some, so please be assured that the matter has received a great deal of thought beginning years before the protocols were published. You may find it rewarding if you read the SysLink protocol's Language Specification section before proceeding. )

To insure universal compliance and cooperation, all of the environment server's requirements will be met primarily in Standard American English. ( Standard American English subsumes the ten Arabic digits.)

Additionally, the environment server may publish in any other language or languages as determined by its authority.

-- . --

-- environment code --

Creation :
      Each environment will be assigned a unique code as part of its
          definition. That will be its identifier.
      The defining authority will select that code.
      It will consist of upper case American English characters,
          which subsume the ten Arabic digits.
      It will be as short as possible, but at least three characters.
      Please see SysLink's Language Specification section.
      And please see SysLink's Permitted Characters sub-section.

Example :
      Identifier : TER
      Environment : Planet Earth, or Terra.
      Physical locale : The planet.
      Earth's temporal environment is TER.
      (This is a temporary place-holder and without authority.)
      (Offered for use until a defining authority is established.)

-- . --

-- environment identifier usage --

When used with a coredate value, the environment
      identifier will be properly delimited by two characters
      to create an envelope.
The left delimiter, before the identifier, is ASCII character 60,
      a less-than symbol (<).
The right delimiter, after the identifier, is ASCII character 62,
      a greater-than symbol (>).
The identification of the temporal environment will be
      affected by prefixing the date-time string with the
      delimited environment identifier.
Neither blanks nor nulls are permitted within or after the
      envelope.

The expression of a coredate may include its environment identifier. Transmission of coredate values may include their environment identifiers. Use of an environment identifier identifies that value as a temporal expression of that environment.

-- . --

-- environment's coredate string --

Each authority may redefine the coredate string to conform to its environment's characteristics and to meet its environment's needs.

The authority should master the theory of temporal value meaning, expression, and manipulation and its horological foundations before undertaking this task.

The number of formats will be that of the protocol's basic definition. One or more formats may be explicitly deprecated for clarity.

The redirector will not be redefined.

Each character attribute may be redefined for the new environment.

Every temporal environment's start date will be synchronized with the base start date; i.e., the zero value of each will be calculated and positioned to force occurrance simultaneity with the Terran zero value. Ergo, all environments can be synchronized at will regardless of the CoreDate's universal domain complexity.

All environments use the same number of character positions in coredate object strings.

All characters remain required, but some may be deprecated beginning with the rightmost characters. Characters that are deprecated by definition will always carry values of zero (0).

All environments use the same method of relative value positioning within the coredate object, which follows the basic specification.

Each environment may employ its own time slicing conventions that may include embedded locally significant constructs. (See the Unit Basses section.)

-- . --

-- time zones --

The environment authority may define and implement time zones. Time zone attributes, identifiers, and offsets will be entirely specified by each defining authority without respect to any other environment.

Time zone geometry and location will be entirely specified by the authority.

Time zone specification and usage in all environments will adhere to specifications in the Time Zones section.

-- . --

-- anomaly correction --

Anomaly correction is the responsibility of the defining authority. Such correction that is accomplished through explicit specification, such as leap years, will be published as part of the definition.

-- . --

-- relativity --

Relativistic Effects
      Relativistic effects are accounted for through locally simplistic absolute values; relativistic redefines and relativistic temporal positioning are disallowed. The zero base is synchronized with TER throughout all systems. The local expression of any remote date will be expected, therefore, to be synchronous throughout all systems. In other words, relativistic affects are an unfortunate (for mere Man) reality in this universe, and we will account for them by ignoring them. (Precise despite its humor.)

Relativistic Slippage
      Relativistic slippage will be treated independently of relativistic effects. If there is local relativistic slippage relative to the Terran environment, it will be published with the definition so that all environments can remain synchronized. The use of embedded locally significant constructs to obviate slippage is permitted only where the constructs are published by the defining authority in a manner that makes all remote expressions of local values synchronous.

-- . --

-- examples --

A symbolic representation:
      <ENV>YYYYMMDDHHMMSSNNNNNNN<ZZ>

Example:
      <MAR>201001040000000-
The date is 2010 BC in the martian environment and may be converted to the local date in another environment. (This example is illustrative only, and neither the environment symbol nor the environment specification is authoritative. )

Example:
      <TER>2017010400000000
The date is the fourth of Jan in 2017 in the current time zone on earth. (ibid)

_________________________
CoreDate
Protocol
Section
Unit Basses

A cyclic and astronomical basis for time is not required. The number of revolutions of the electron in a hydrogen atom since the beginning could be the basis. But that would have its own problems; e.g. the precise specification of the universal ionization termination. Any basis will have its own problems. But we know that, regardless of their problems, astronomical cycles are inherently meaningful to humans and to their systems. Therefore, the expression of any time within the standard will be astronomical cycle-based, but may be otherwise explicitly stated by the defining authority.

The choice of cycles will be made when the environment is defined. Those cycles will be used to zero the expression base. (See the Temporal Environments section.)

Environments within the solar system are assumed to be helio-centric, although that is not required. Helio-centric values will usually be easier to synchronize than others. An example of a non helio-centric cycle-type in the solar system might be the revolutions around a more local body.

Galactic environments within the local galaxy are assumed to be galactic-centric unless explicitly stated otherwise by the defining authority.

Cycle expansion and contraction are permitted. For example, it would be permissible to define a local cycle that spans a thousand TER cycles.

__________________________________________________
__________________________________________________
CoreDate
Appendices

_________________________
CoreDate
Appendix
Intractable Problems

( The fact that these are intractable will not be allowed to make them impossible or insurmountable.)

-- . --

-- the target audience --

This discussion is not necessary for most CoreDate users. Some may even find it needlessly distracting from the practical matters in which they are interested. It is shared for those who are interested in the abstracted theoretical foundations, and for those who need to understand as much as possible, such as those who will become temporal environment authorities; whether welcome or not, the public will seek authoritative assistance with such matters after the CoreDate forces them to light.

-- . --

-- the domain --

The attempt to construct a useful date-time protocol encountered intractable problems, some of which may be insurmountable partly due to our self-imposed constraints and objectives. Generally speaking, we are attempting in the CoreDate protocol to construct a precise, coherent, and logical protocol for something that is none of those, and which exists only in the minds of Man (See the "Nature Of Time"), but which is needed for practical purposes.

Those of us in the natural and computer sciences are drawn to the precisely measured and logically presented. All else makes us shudder. Unfortunately, you will find in the following that the subject of "time" contains problems that are a mixture of precise systems and fuzzy sociological and psychological matters. That mixture denies a quick solution, but let us try to state some of the problems as a prelude and preparation for solutions. Hopefully.

Again, although these are certainly intractable, some are subject to eventual solution.

-- . --

-- ambiguities --

There are inconsistencies and ambiguities in our use of the time concept. The first division of the time object is an example; is the first hour division of the day number zero, or is it the twenty-fourth hour of the preceeding day, or is it number one? We use all three personally and in our systems, sometimes simultaneously, and anybody who has programmed in MS Windows knows that a system that steps into a new day can be unreliable because of it. The answer to the question depends upon how time is being addressed. Are time units being addressed as historical events or are they being addressed as horological increments, and what do the coredate numbers actually represent; what is their basic function?

Those questions are important in the construction of basic logic components in the CoreDate structure. You will sense them in the protocol's basic definitions in the Basic Specifications section. No attempt to answer them will be made now because an operational protocol is needed immediately, but they must be answered eventually for the protocol's sake.

-- . --

-- internal component conflict --

There is a profound inconsistency at the foundation level of the time concept as it is used by people at the inception of the CoreDate protocol. Component protocols of the time object sometimes seem alien to each other in normal usage. Note the different handling of months and minutes. If the first stated month and minute are the ones in which we now reside, then the stated month in which we reside is number one even if we are in day ten of that month, whereas the first stated minute in which we reside is number zero, nothing, despite the passage of thirty seconds. The confusion worsens when we move into the second unit. The statement of a coherent time unit is made awkward by those component protocols that implicitly conflict by defining time differently. (See its illustration in the problematic range specification in the Basic Specifications section.)

A graphic illustration that places a year of months on a timeline.
>--- 1 ---- 2 ---- 3 ---- . . . . ---- 12 --->
Months, days, and years, the calendar elements of time are left loaded regardless of their components.
The same timeline, but showing its hours.
>--- 0 ---- 1 ---- 2 ---- . . . . ---- 8,759 --->
The clock elements of time are right loaded, so when we are in hour one, it is shown as hour nothing. The last hour, number 8,760 is never seen because its components are exhausted, and we have started the next year's timeline.

The source of the problem seems to be the simplistic nature of the agrarian environment in which the time concept originated. (See the "Nature Of Time".) That concept was actually a solution to many problems and was sophisticated when created and refined in subsequent centuries, so we are indebted to those who did it. Through no fault of theirs, the problem now is that we must force that old concept to serve precisely and to serve for more complex purposes in our more complex environment. Furthermore, that old concept cannot be discarded without destroying the foundation elements that must be retained to psychologically support current society and to support existing systems. Notice that, although there are sixty minutes in an hour, the Table Of Value Strings section of the TER environment example goes only to fifty-nine.

( Let us not denigrate those original developers; they had little reason for doing otherwise, whereas the nonsensical use of zeroth (whatever that means) values in our programming languages is illogical, rediculous, and has little defense.)

-- . --

-- internal logical conflicts --

Part of the problem is that we unconsciously typify time as divided into two parts; a clock part and a calendar part. Although they address the same time concept, those parts are psychologically independent, so they are assigned different notation conventions, each with its own protocols. That psychology-based logical structure was valid and reflected reality in former ages, but causes problems in our context.

In any case, we must attempt to correctly state our new protocol in a manner that makes it useful to us and to our systems, while retaining its old meanings for the continuity of us and our systems.

The solution for the moment is that we will simply plug existing usage into the coredate characters. Each component will be stated and will be used as it is currently commonly used. Problems immediately come to mind, but we must get the protocol moving, so we will try to handle problems as they impinge upon operations.

-- . --

-- an unrecognized dichotomy --

Another problem lies in an ill-defined psychological dichotomy that is seldom ever verbalized. Although we, as a civilization, present the time concept as a demonstrable part of reality, we think of it simultaneously as discrete increments and as a flowing continuum, thereby destroying its reality. (No, we will not participate in the quantum mechanics mess, so please do not suggest it.)

Although possibly interesting and solvable, that particular problem is minor and intractable, so it will be ignored by the CoreDate project at this time.

Fortunately, beginning in the nineties, I (* See note below.) observed a rapid psychological digitization of most people that is so profound that it now seems to be a cultural characteristic of which they are unaware, and like much of the American culture, probably quickly spread world-wide. I believe that the more realistic internal analog model that Man used in the past has been supplanted by a digital construct.

Therefore, I expect that phenomenon to cause most people to not even notice that dichotomic shortcoming in the protocol. And I expect it to cause system developers to unconsciously work around it as they wrestle with more complex matters, so few will notice the problem.

( * Forgive me for the first-person interjection, but this should be recognized as a personal observation made by my aberrant nature and not as a credible scientific sociological study.)

( As a test, ask somebody for the time, and instead of the old fashioned "Oh, around two.", you will hear "One fifty three." with god-like certitude. Digitization. )

-- . --

-- comments --

Any comments on these or other problems will be appreciated. Send to john in this domain, with CoreDate as the subject.

Before commenting, be sure to read the "Nature Of Time" observation to insure your theoretical base in case you have not yet been impacted by that observation. It may be upsetting, but it will ease and assist your abstract thinking after internalization.

_________________________
CoreDate
Appendix
Definitions

-- the time concept --

Any commonly accepted set of mechanical or electromagnetic state changes or physical movements with which other state changes or physical movements can be synchronized. ( 1* )

-- date units --

The major divisions of time, which are presented as units. ( 2* )

-- time units --

Arbitrary divisions of the smallest date unit. ( 3* )

-- CoreDate --

A protocol that directs the simple, but rigorously controlled, expression of the identity of a time instance. ( 7* )

( When used in lower case, see the following "coredate object". )

-- coredate object --

A string of characters constituting the object that is the expression of the identity of a time instance; i.e., a string of characters that is a valid coredate. ( 7* )

( When used in mixed case, see the preceeding "CoreDate". )

-- form --

One of the specified formats for coredates. ( 7* )

-- temporal environment --

A place, space, or conceptual environment to which no existing temporal environment definition was applicable, necessitating its own complete temporal definition to enable a shared synchronized observance of time within it. ( 4* )

-- time zones --

Divisions of a temporal environment that support local expression of times in all zones while retaining the integrity of the temporal environment. ( 5* )

-- beginning --

The beginning is implicitly set by each temporal environment within its definition. ( 6* )

-- start date --

The start date allows the permanent synchronization of all temporal environments in the CoreDate domain. ( 8* )

-- comments * --

      1. That definition includes no metaphysical, psychological, sociological, or fantasy component.
      If you are one of those who have trouble accepting it, please read the "Nature Of Time" when you have a free moment.
      Although it may become better articulated, this will soon be the universal definition. It will then suddenly seem obvious and future generations will grasp our fantasy concept no better than do we.
      2. The Terran environment's date concept is a concatenation of three local astronomical cyclic motions. A temporal environment's defining authority is free to use or discard the "date" concept.
      3. The Terran environment's smallest date unit is divided into 24 units called hours, which are each divided into 60 units, which are each divided into 60 units. A temporal environment's defining authority is free to use or discard the "time unit" concept.
      4. For example, the date and time on earth cannot serve people on Mars.
      5. Time zones are entirely defined by the environment's defining authority, so they might or might not resemble those of the prime Earth environment. The authority will specify offsets for each, which specify their relations.
      6. The beginning for a temporal environment is not necessarilly the zero date, and is not necessarilly the beginning of the universe. It is set by its defining authority.
          For the Terran temporal environment, the beginning was set at the limit of its defined digits, which is about twelve thousand years ago, and about nine thousand before the zero date.
          The protocol also allows creation of universal environments that can span or exceed the existence of the universe.
      7.
      The protocol was intended primarily for system-use.
      It was made to also be quickly and easily red by people.
      Short forms were later added for people.
      A coredate object is a string of digits that is simpler to read and understand than any prior date-time method. The rigorous protocol presentation makes it seem complex.
      8. To affect universal domain synchronization, the protocol requires every environment to force zero occurrance simultaneity with the Terran zero value.

-- --

_________________________
CoreDate
Appendix
Release History

The following shows history of protocol changes published in the Current Release section. See that section for "release" definition.

Release:     180317
Purpose:     Protocol was not changed, but was
                    extensively reworded for lucidity.
Proposed:   Was not proposed.
________________________________________

Release:     180218
Purpose:     Upgraded the Environment Specification.
Proposed:   20171214.
________________________________________

Release:     180101
Purpose:     Amended the Time Zone specifications.
Proposed:   20171214.
________________________________________

Release:     171212
Purpose:     Purged and upgraded the Time Zones section.
________________________________________

Release:     171113
Purpose:     Added two people-friendly abbreviated
                    coredate forms.
________________________________________

Release:     171009
Purpose:     Extensive restatement for clarification without
                    protocol changes.
________________________________________

Release:     170908
Purpose:     Release identifier expanded from five to six digits.
________________________________________

Release:     081203
Purpose:     Clarification of the environment specification.
________________________________________

Release:     070203
Purpose:     Provided an expansion and refinement of the
                    protocol. No changes were made to previously
                    published specifications.
________________________________________

Release:     060102
Purpose:     Concept initialization.
This date may be used in references as the protocol's publication date.

_________________________
CoreDate
Appendix
Synchronization Protocol

( Under consideration and(or) construction. Do not use. )

-- . --

-- proposal --

This synchronization protocol is being considered with analysis of the needs and the problem space. It is not yet ready. Any part of it is subject to change and(or) deletion without notice until it is either implemented or discarded.
      Implementation will be done by removal of this introduction.
      Failure to implement will be signalled by its entire removal.
      Some consideration is being given to incorporating the synchronization protocol into the CoreDate protocol.
      Proposal publication date is 20171010, using the short form.

Comments will be received with appreciation.

-- . --

security And universalization

Based upon work done for the SysLink protocol, security and universalization are considered in this protocol's construction. Language and character specifications are based on extensive and complex considerations that can be understood only by reading their explanations in the SysLink protocol. Security matters include specifications for literals, English, unicode, ASCII characters, etc.
      Please see SysLink's Language Specification section.
      And please see SysLink's Permitted Characters sub-section.

-- . --

communication protocols

This protocol specifies no communication protocols, and specifies neither sender nor responder. However, to insure the accuracy of the time values in the messages, automated systems are almost required.

For its advanced features, the SysLink communication protocol is recommended for CoreDate synchronizations.
( If your system is SysLink-deficient (SLeD), please consider upgrading. It provides far more support than can be described here. Ignore the SysLink document's size, because most of it is an extensive implementation tutorial appendix that covers advanced communication topics for specialists in many different fields.)

-- . --

Proposed synchronization protocol follows.

-- . --

-- purpose --

The synchronization protocol supports the CoreDate protocol. Its objective is to allow autonomous systems to synchronize time with remote systems with security, speed, and reliability.

-- . --

-- the event --

A synchronization event consists of four actions :
      A request message transmission,
      a response message transmission,
      the result calculation,
      and the local update.

-- . --

-- synchronization servers --

Any systems may serve synchronization requests.
Requests may be ignored for security purposes.
Most requests should be sent to a temporal environment server.
Environment servers are expected to synchronize.
No others are required to serve synchronization requests.

-- . --

-- language --

The use of literals and the control of hidden characters
      require English in the messages.
Unicode is not permitted. Only ASCII characters are used.
Deviation from this specification should be treated as an
      attempted security breach, especially on the server.
( Please see SysLink's Language Specification section.)

-- . --

-- result calculation --

1.   Determine the amount of time that the reply was in transit.
2.   Add that to the value in row three (3).
3.   That will be the current datetime of the other system.
4.   Save that and the current local time.
5.   Adjust the current local time accordingly.

Note that two transit times are provided for cross checking. For the request and for the response. Their use is the responsibility of the requester.

( It is important that the internal processing duration of the local system not be included in the stated time; i.e., the times sent and received should be as close as possible to the actual times sent and received.)

-- . --

-- datetime values --

Values in the message must be the extended coredate form.
Values are the transmitter's local datetimes.
In the event of a system loss-restart, the datetime may be
      sent as all zeros.
Any deviation from this content specification should be
          considered an attempted security breach.

-- . --

-- row and req columns --

The "row number" and "required" columns of the following layout tables are descriptions in this document, and must not be included in the messages.

The "required" column shows required rows. A row is required if it has an asterisk in that column.

-- . --

-- line breaks --

Each row is terminated by ASCII characters 13 and 10.
Those characters will be used only for that purpose.
Row terminators will immediately follow row contents.
      There will be no space between them.
Other unprintable characters are not permitted in these messages.

Deviation from this line break specification should be treated as an attempted security breach.

-- . --

-- rubric --

The SysLink envelope header's row 23 "rubric" slot should contain either
      "coredate synchronization request" or
      "coredate synchronization response".

-- . --

-- relativity impact --

Ignore it. Any relativity influence is handled by the designs of this protocol and the CoreDate protocol.

-- . --

-- message row contents --

To support machine processing and automatic activity,
      only the designated data will be in each row.
      There will be no description, comment, or label.
      ( For example, the content of row three will be only a
          string of digits; i.e., the coredate value.)
The row separator will be only that specified below.
Where a row has no data, it will be transmitted as an empty
      row with terminators. It will not contain a blank.
The entire message will contain blank characters only
      as word separators where needed.
Any deviation from this content specification should be
          considered an attempted security breach.

-- . --

-- row descriptions --

The following describe the rows in a transmission.

-- row descriptions --
-- message delimiter rows --

Row 1, 2, and 10.
The first, second, and last rows of each message are literals,
      as shown in the following layout tables, that identify and
      delimit the message.
Note the required lower case characters.
Row 1 is "coredate".
Row 2 is "synchronization request".
Row 10 is "message termination".

Deviation from this delimiter specification should be treated as an attempted security breach.

-- row descriptions --
-- datetime sent --

Row 3.
Accuracy of this value is important for both the requester and the responder because both will be used in the calculation of the final time adjustment.

-- row descriptions --
-- local accuracy row --

Row 4.
"Local accuracy" is the datetime precision that is maintained by the transmitter.
      ( Format is currently not specified, but may be reconsidered in the future.)

-- row descriptions --
-- environment identifier row --

Row 5.
The environment identifier is required.
Environment is the transmitter's.
It is on a separate row to speed the server's processing.
It is sent without an environment identifier envelope since
      it is on a dedicated line, to save processing time.

Deviation from this environment identifier specification should be treated as an attempted security breach.

-- row descriptions --
-- time zone row --

Row 6.
Times must be of each environment's primary time zone.
The entry of a time zone is optional.
It is on a separate row to speed the server's processing.
It is sent without a time zone envelope since it is on
      a dedicated line, to save processing time.

-- row descriptions --
-- request identifier row --

Row 7.
The request identifier is optional.
It is strongly recommended for administration.
It is unique to each request.
It is generated by the requester.
It is returned on the response.
A server may require it.
A recommended identifier is a random 62 byte string.
Maximum row length is 100 characters, excluding terminator
      characters.
That identifier, with the address and datetime, should be
      sufficient for a heavily trafficked environment.

See the SysLink Identifiers sub-section for additional discussion.

-- row descriptions --
-- requester address row --

Row 8 in the request.
The requester address is optional.
It is strongly recommended for administration.
A server may require it.
Maximum row length is 100 characters, excluding terminator
      characters.

-- row descriptions --
-- datetime request received --

Row 8 in the response.
Accuracy of this value is important because it will be used in the calculation of the final time adjustment.

-- row descriptions --
-- reserved row --

Row 9 in the request.
The reserved slot is for future use by the protocol.
Until it is used, any value in it will be a security error.

-- row descriptions --
-- error row --

Row 9 in the response.
An error message may be returned by the server.
Required values must be returned with it, when possible.
Maximum row length is 100 characters, excluding
      terminator characters.
An error is any value, event, or state that prevents a
      desired, valid, secure, and coherent response.
A complex error for which a short message will not suffice
      may be indicated by the word "contact" followed by a
      space and followed by an address or phone number.

-- row descriptions --
-- message delimiter rows --

Row 10.
See description above for rows 1, 2, 10.

-- . --

-- end of row descriptions --

-- . --

-- message structures --

Request Message

Response Message

-- --

End of appendices To The CoreDate Protocol

__________________________________________________
__________________________________________________

Addendum
The Nature Of Time
(A Critical Assessment)

This is a critical assessment.
      Caution : Diffusion of this idea through society is not complete. If you have not been exposed to it, you are over the age of forty, and you can understand the presentation, this can be akin to a strong culture shock.

Please click here to load the "Nature Of Time" dissertation from the theory document.

Web site and technology
Copyright 1999 - 2021 John Ragan

Web site is maintained with Notepad.
By intent, so don't bother me about it.