×

from:

message:

how many fingers, thumbs, and toes do most people have?

Loading comments …

current local time

current standard time

TC Epoch

25

25

( 48-12-20 9:44:50 TC )
( 48.12.20,9.44.50 TC )

( 48-12-20 9:44:50 TC ) ( 48,12/20.9_45:15TC0 )

( 48-12-20 9:44:50 TC ) ( 48,12/20.9_45:15TC0 )

(TC is ahead of UTC by seconds*)

(UTC is behind TAI by seconds*)

(TAI is ahead of TC by seconds*)

*Disregarding the year/month/day

(UTC is behind TAI by seconds*)

(TAI is ahead of TC by seconds*)

*Disregarding the year/month/day

(TC is ahead of UNIX by seconds)

(TAI64 is ahead of UNIX by 2^62 + seconds)

(TAI64 always ahead of TC by 2^62 - 863990 seconds)

(TAI64 is ahead of UNIX by 2^62 + seconds)

(TAI64 always ahead of TC by 2^62 - 863990 seconds)

Also see comparative tables for leap seconds and the seasons.

CLOSE

- A cycle's darkest point is often treated as the beginning of a cycle, therefore, the terran computational calendar chose to synchronize itself with the shortest day of the year in the northern hemisphere.
- The UNIX Epoch is often thought of as the beginning of modern computerized timekeeping, so (roughly*) 10 days before the UNIX Epoch was chosen.
- UTC and TAI have both been redefined since their inceptions (the last redefinition was at the beginning of 1977), and because of this UNIX time is loosely defined. So instead of defining in terms of UNIX Time, the terran computational epoch is defined in terms of this last redefinition whereby corrections were applied to TAI atomic clocks to account for gravitational time dilation by redefining the output to represent atomic time measurements made at mean sea level (the geoid). Therefore, officially, the terran computational epoch occurred at 221788790 ((365*5 + 366*2 + 10)*86400 - 10) SI seconds measured at the geoid before 1977-01-01 00:00:00 TAI.

A year base is optional and is appended to the right hand side of the 'TC' in a given date's designator and together they effectively create their own distinct designator. Letting

Therefore, if we want to write a date 10 years after the current date of 44TC and the last known leap second occurred at the end of year 42TC, we could use 43 or 44 as the year base to write this date as 54TC43 or 54TC44 (but not 54TC42 because it will not account for the last leap second that occurred at the end of year 42TC).

The optional 'datemod' (which stands for 'date modification') field takes the place of traditional timezones and offsets by adding or subtracting to/from the date instant.

If the preceding delimiter of a datemod is '-', the datemod value is negative and will be subtracted from the current date. Conversely, any other preceding delimiter constitutes a positive the datemod value that will be added to the current date. If the datemod is equivalent of 0, it is unnecessary (and discouraged, depending on your purpose) to include a datemod since any designator automatically assumes a +0 datemod.

There is always at least 1 leap day per year. In years that are a multiple of 4 but not of 128, an additional leap day is included resulting in 2 leap days that year. Adding leap days in this fashion is extremely efficient and will keep each year synchronized with the northern winter solstice.

There will be no leap year day when the remainder of dividing the year by 128 is 0 (when the year is exactly divisible by 128 & the year is a multiple of 128). This includes the year 0 and any negative or positive multiples of 128, so, for example, there would be no leap years in the years …, -512, -384, -256, -128, 0, 128, 256, …

Assume an average year with 1 leap year day every 4 years = (365 + 365 + 365 + 366) / 4 = 365.25 days

Let YEAR

Let YEAR

Let DIFF be the number of days per year that must be made up for each year

DIFF = YEAR

= 0.0078103 days per year

Let NUMYEARS

NUMYEARS

= 1 day / 0.0078103 days per year

= 128.036054953 years

128.036054953 years is extremely close to 128 years, so that's why 128 is chosen as the point to omit a leap year.

Any leap seconds issued by the IERS within the bounds of a given terran computational year will manifest themselves in that year's minimonth. The terran computational calendar does not account for erratic leap duration before 0TC, so to ignore all leap seconds, apply a year base of 0 to a date's designator (TC0). There have been 25 leap seconds since 0TC, all of which occurred in different years (2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 15, 18, 20, 21, 22, 23, 24, 26, 27, 29, 36, 39, 42). Check out the following UTC and terran computational leap second

1972-12-31 23:59:60 UTC

1973-12-31 23:59:60 UTC

1974-12-31 23:59:60 UTC

1975-12-31 23:59:60 UTC

1976-12-31 23:59:60 UTC

1977-12-31 23:59:60 UTC

1978-12-31 23:59:60 UTC

1979-12-31 23:59:60 UTC

1981-06-30 23:59:60 UTC

1982-06-30 23:59:60 UTC

1983-06-30 23:59:60 UTC

1985-06-30 23:59:60 UTC

1987-12-31 23:59:60 UTC

1989-12-31 23:59:60 UTC

1990-12-31 23:59:60 UTC

1992-06-30 23:59:60 UTC

1993-06-30 23:59:60 UTC

1994-06-30 23:59:60 UTC

1995-12-31 23:59:60 UTC

1997-06-30 23:59:60 UTC

1998-12-31 23:59:60 UTC

2005-12-31 23:59:60 UTC

2008-12-31 23:59:60 UTC

2012-06-30 23:59:60 UTC

3.0.11,0.0.0 TC

4.0.11,0.0.0 TC

5.0.10,0.0.0 TC

6.0.10,0.0.0 TC

7.0.11,0.0.0 TC

8.0.11,0.0.0 TC

9.0.10,0.0.0 TC

10.0.10,0.0.0 TC

11.6.24,0.0.0 TC

12.6.24,0.0.0 TC

13.6.23,0.0.0 TC

15.6.24,0.0.0 TC

18.0.10,0.0.0 TC

20.0.11,0.0.0 TC

21.0.10,0.0.0 TC

22.6.24,0.0.0 TC

23.6.24,0.0.0 TC

24.6.24,0.0.0 TC

26.0.10,0.0.0 TC

27.6.24,0.0.0 TC

29.0.10,0.0.0 TC

36.0.11,0.0.0 TC

39.0.11,0.0.0 TC

42.6.24,0.0.0 TC

1973-12-20 23:59:59 UTC

1974-12-21 23:59:59 UTC

1975-12-21 23:59:59 UTC

1976-12-20 23:59:59 UTC

1977-12-20 23:59:59 UTC

1978-12-21 23:59:59 UTC

1979-12-21 23:59:59 UTC

1980-12-20 23:59:59 UTC

1981-12-20 23:59:59 UTC

1982-12-21 23:59:59 UTC

1983-12-21 23:59:59 UTC

1985-12-20 23:59:59 UTC

1988-12-20 23:59:59 UTC

1990-12-21 23:59:59 UTC

1991-12-21 23:59:59 UTC

1992-12-20 23:59:59 UTC

1993-12-20 23:59:59 UTC

1994-12-21 23:59:59 UTC

1996-12-20 23:59:59 UTC

1997-12-20 23:59:59 UTC

1999-12-21 23:59:59 UTC

2006-12-21 23:59:59 UTC

2009-12-20 23:59:59 UTC

2012-12-20 23:59:59 UTC

3.13.1,0.0.0 TC

4.13.2,0.0.0 TC

5.13.1,0.0.0 TC

6.13.1,0.0.0 TC

7.13.1,0.0.0 TC

8.13.2,0.0.0 TC

9.13.1,0.0.0 TC

10.13.1,0.0.0 TC

11.13.1,0.0.0 TC

12.13.2,0.0.0 TC

13.13.1,0.0.0 TC

15.13.1,0.0.0 TC

18.13.1,0.0.0 TC

20.13.2,0.0.0 TC

21.13.1,0.0.0 TC

22.13.1,0.0.0 TC

23.13.1,0.0.0 TC

24.13.2,0.0.0 TC

26.13.1,0.0.0 TC

27.13.1,0.0.0 TC

29.13.1,0.0.0 TC

36.13.2,0.0.0 TC

39.13.1,0.0.0 TC

42.13.1,0.0.0 TC

Erratic leap duration refers to unknown or unstable leap duration, such as IERS issued leap seconds. No erratic leap duration occurs before 0TC, so, to ignore all erratic leap duration apply a year base of 0 to a date's designator (TC0).

If other standardized methods ever arise to account for leap drift, the resulting remaining shift in duration will be rounded up to a terran computational second, treated as erratic leap duration, and be added to a given year's minimonth. And any resulting remainder will be used to calculate the next year's erratic leap duration. A year base of 0 (TC0) ignores all erratic leap duration.

'TC' is an acronym for 'terran computational'. Terran computational dates and written timestamps must utilize a 'TC' and optionally concatenated positive integer year base as a designator. A 'TC' designator without a year base signifies that all known erratic leap duration should be accounted for. A 'TC' designator with a given year base,

Delimiters separate date fields from one another. The only 8 acceptable delimiters are space, plus, comma, minus, dot, slash, colon, underscore ( +,-./:_) (UTF8 hex codes 20, 2b, 2c, 2d, 2e, 2f, 3a, 5f). A delimiter directly before the designator is optional. For exact rules regarding delimiters, view the algorithm for formatting & parsing.

The following is a comprehensive list of rules for formatting and parsing terran computational dates:

- The order of fields is: year, month, day, hour, minute, second, fraction, designator, datemod.
- The only characters that may be used in a terran computational date are the following 26: ' +,-./1234567890:CDHLMQTW_' corresponding to UTF8 hex codes (20, 2b, 2c, 2d, 2e, 2f, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 3a, 43, 44, 48, 4c, 4d, 51, 54, 57, 5f).
- Each delimiter must comply with the delimiter section.
- All fields must have a delimiter on each side unless specified otherwise.
- Each date field must comply to its corresponding range for each unit in the basic time measurement section, the designator section and the datemod section.
- All fields may represent a positive integer value. Only the year field or the datemod field may represent negative values. If the value of either the year field or the datemod field represents a negative value, the field's preceding delimiter must be the '-' character.
- The delimiter to the right of the datemod field is always optional and generally discouraged.
- The delimiter to the left of the year field is required if its value is negative, but is otherwise optional.
- If the datemod is a value of zero, it is optional. If the datemod has been omitted, the delimiters on either side are optional. If a non-zero datemod is present, the delimiter to the left is always required.
- The delimiter to the left of the designator is always optional.
- If the value of the field to the left of the designator is zero, it is optional.

One week is defined as the duration of 7 days. Any integer number of weeks can be expressed by appending a W as a datemod. For example, 44TC+39W is the equivalent of 44.9.21TC, or if you want to do away with years, and use weeks for the highest unit, you could write this date as TC+2334W5D25

One quarter is defined as the duration of 13 weeks. Any integer number of quarters can be expressed by appending a Q as a datemod. For example, 44TC+3Q is the equivalent of 44.9.21TC, or if you want to do away with years, and use quarters for the highest unit, you could write this date as TC+179Q7W5D25

Just like years, decades, centuries, and millennia also function as integers whereby decade -1 covers years -10 through -1 and decade 0 covers years 0 through 9; millennia -1 would cover years -1000 to -1 and millennia 0 would cover years 0 through 999.

The terran computational calendar does not implement or support traditional timezone abbreviations, but it does allow for dynamic date modifications, or 'datemods' which easily represent regional time.

To convert a timezone abbreviation into a datemod, determine the UTC offset in hours, minutes or seconds multiply it by -1 to get the datemod. For Instance, the PST timezone has an offset of -7 hours in UTC, so the datemod would be +7H in the terran computational calendar.

JST, a +09:00 offset in UTC is a -9H datemod. NST, a -03:30 offset in UTC is a +210M TC datemod. Note that these datemods can also be expressed in different ways.

In UTC, there are a large number of timezones, each with their own set of rules which are even themselves possibly subject to change. Therefore, for reasons of transparency, timezones are not implemented in terran computational dates. Although not as descriptive and verbose, datemods are more well defined, easier to calculate, and they do not require complicated lengthy tables of offsets (unless you are of course converting between another calendar system which utilizes timezones). Timezones may still be useful for referencing datemods, but they are still not permitted for use in terran computational dates.

While the terran computational calendar accommodates quarters, the only season/solstice that the terran computational calendar tracks, within some degree of extreme ease, is the beginning of winter and the winter solstice of the northern hemisphere which falls around the beginning/end of each year. But even that is not constant, so in order to determine the exact time of an equinox, solstice, or season, please check out the follow

Seasons generally still start within a day of the following corresponding terran computational dates: (*=any given year) *.0.0TC (n. winter solstice), *.3.5TC (n. vernal equinox), *.6.13TC (n. summer solstice), *.9.24TC (n. autumnal equinox) which in turn are within a couple days of their corresponding quarter: *.0.0TC, *.3.7TC, *.6.14TC, *.9.21TC .

2011-12-22 05:30:00 UTC

2012-12-21 11:12:00 UTC

2013-12-21 17:11:00 UTC

2014-12-21 23:03:00 UTC

2015-12-22 04:48:00 UTC

2016-12-21 10:44:00 UTC

2017-12-21 16:28:00 UTC

2018-12-21 22:23:00 UTC

2019-12-22 04:19:00 UTC

2020-12-21 10:02:00 UTC

42-00-00 05:30:00 TC

43-00-00 11:12:00 TC

44-00-00 17:11:00 TC

44-13-01 23:03:00 TC

46-00-00 04:48:00 TC

47-00-00 10:44:00 TC

48-00-00 16:28:00 TC

48-13-01 22:23:00 TC

50-00-00 04:19:00 TC

51-00-00 10:02:00 TC

2011-03-20 23:21:00 UTC

2012-03-20 05:14:00 UTC

2013-03-20 11:02:00 UTC

2014-03-20 16:57:00 UTC

2015-03-20 22:45:00 UTC

2016-03-20 04:30:00 UTC

2017-03-20 10:29:00 UTC

2018-03-20 16:15:00 UTC

2019-03-20 21:58:00 UTC

2020-03-20 03:50:00 UTC

41-03-04 23:21:00 TC

42-03-05 05:14:00 TC

43-03-05 11:02:00 TC

44-03-05 16:57:00 TC

45-03-04 22:45:00 TC

46-03-05 04:30:00 TC

47-03-05 10:29:00 TC

48-03-05 16:15:00 TC

49-03-04 21:58:00 TC

50-03-05 03:50:00 TC

2011-06-21 17:16:00 UTC

2012-06-20 23:09:00 UTC

2013-06-21 05:04:00 UTC

2014-06-21 10:51:00 UTC

2015-06-21 16:38:00 UTC

2016-06-20 22:34:00 UTC

2017-06-21 04:24:00 UTC

2018-06-21 10:07:00 UTC

2019-06-21 15:54:00 UTC

2020-06-20 21:44:00 UTC

41-06-13 17:16:00 TC

42-06-13 23:09:00 TC

43-06-14 05:04:00 TC

44-06-14 10:51:00 TC

45-06-13 16:38:00 TC

46-06-13 22:34:00 TC

47-06-14 04:24:00 TC

48-06-14 10:07:00 TC

49-06-13 15:54:00 TC

50-06-13 21:44:00 TC

2011-09-23 09:05:00 UTC

2012-09-22 14:49:00 UTC

2013-09-22 20:44:00 UTC

2014-09-23 02:29:00 UTC

2015-09-23 08:21:00 UTC

2016-09-22 14:21:00 UTC

2017-09-22 20:02:00 UTC

2018-09-23 01:54:00 UTC

2019-09-23 07:50:00 UTC

2020-09-22 13:31:00 UTC

41-09-23 09:05:00 TC

42-09-23 14:49:01 TC

43-09-23 20:44:00 TC

44-09-24 02:29:00 TC

45-09-23 08:21:00 TC

46-09-23 14:21:00 TC

47-09-23 20:02:00 TC

48-09-24 01:54:00 TC

49-09-23 07:50:00 TC

50-09-23 13:31:00 TC

The cycles of the moon, like most objects in our solar system including the earth, are somewhat erratic. And although months are a general approximation of lunar cycles, the terran computational calendar makes no attempt to track these cycles explicitly.

Milankovitch Cycles include the many cycles of the earth whose periods are on timescales of tens of thousands of years. Since these periods are so extensive and also so erratic, they are generally incredibly difficult to predict within any great degree of accuracy. Therefore, the terran computational calendar does not explicitly track any of these cycles.

Adding leaps days in years that are a multiple of 4 but not a multiple of 128 creates an extremely efficient time keeping method. Much more so than any other simplistic consistent algorithm.

Accuracy is affected by many factors, but compared to other methods of adding and omitting leap days, the accuracy of this calendar has overwhelmingly more accuracy, possibly by a factor of over 100. Our simple demonstrative calculations show the accuracy of the terran computational calendar to the a loss of one day per half million years (based on the 365.2421897 day mean tropical year).

NUMYEARS

DIFF = 0.0078103 days per year

Let NUMYEARS = 128 years

Let DIFF

DIFF

Let DIFF

DIFF

Let ACCURACY be the number of years it will take before this calendar is off by a day

ACCURACY = 1 day / DIFF

454545.45 years

This is a really really long time in calendar terms, though keep in mind that there are many factors that influence a calendar's accuracy and so it is highly unlikely that this calendar is that accurate as there are many other bottlenecks to consider.

Apart from inherent bias, the terran computational calendar intends to be a non-biased neutral calendar for anyone to use for any purpose. Besides its connections to math, computers, atomic time, and astronomy, this calendar does not intend to favor any culture, creed, time, or place. It is a simple idea intending to remain as simple as possible for its purpose, nothing more. Its public domain mark allows people to use the calendar without having worry about most legal restrictions.

The terran computational calendar maintains a very high level of conformity and permanency:

- Each full month, day, hour, minute, second, week, and quarter are of constant length
- Each time measurement unit begins at 0
- Years, decades, centuries, etc. are integer based
- Each year begins near the northern winter solstice
- Each quarter lasts for 3¼ months or 13 weeks
- Calendrical drift is suspended by including leap days in years that are a multiple of 4 but not of 128
- All written dates are unambiguous.
- Any date tells you explicitly how many years, months, days, hours, minutes, and seconds have past since the terran computational epoch.

- Actually start using this calendar by downloading the ubuntu app indicator, using some of the provided code, or using this website.
- Link back to this website.
- Post a comment.
- Promote the calendar through whatever means.
- Help create a larger code base on the terran computational calendar git hub page.
- Write to info ||at|| terrancalender ||period|| com.

This work (terran computational calendar, by http://terrancalendar.com) is free of known copyright restrictions.

For more information, visit its Public Domain Mark.