D'ni timekeeping conversion algorithms

From MYSTlore

Jump to: navigation, search
This page is written from an OOC point of view. Events and elements surrounding the Myst Universe are regarded as fictional.

This is a collection of algorithms to convert between different surface and D'ni timekeeping formats, as implemented either in simple math (or pseudo-code), or in different programming languages.

On October 26, 2007, an email from RAWA to RIUM+ contained the exact conversions from surface time to D'ni time. Whereas before it was impossible to convert from one time system to the other with an accuracy of more than one second every six years, now it is possible for completely accurate conversion to almost infinite accuracy.

Contents

[edit] Surface seconds to D'ni prorahntee and back

  • RAWA has confirmed the length of a D'ni year, or hahr, is exactly 31556925.216 seconds (the estimate for the average mean tropical year (Wikipedia) as it was calculated around 1995, which does not exactly match today's estimates for the average mean tropical year)
  • There are 10×29×5×25×25×25, or 22656250 prorahntee in a hahr.
  • Division of 31556925.216÷22656250=1.392857388844137931.

Therefore, to convert from D'ni time to Surface time, multiply by 1.392857388844137931. To convert from Surface time to D'ni time, divide by 1.392857388844137931.

A simple ratio between the two time systems is that 39 seconds roughly equals 28 prorahn. 39÷28=1.39285714285714, which is off by only 2.46e-7, or 0.000000246 seconds per second, or one second every 4065255 seconds, or 47 days, 1 hour, 14 minutes and 15 seconds - a surprisingly accurate conversion given how low the both the numerator and denominator are. This is more than accurate enough for the construction of a mechanical clock that ticks in both Surface and D'ni time based upon the single timekeeping method (only one spring, pendulum, or quartz crystal that is used to obtain both time systems), especially for one that has to be wound up once every two months or less, and is probably gear the ratio that was used by Gehn in his pocketwatch.


[edit] Conversion accuracy

RAWA has also confirmed that the "Rosetta date", where both time systems exactly converge, is the 21st of April 1991 at 9:54 AM PST, which is the 21st of April 1991 at 16:54:00 in UTC (Wikipedia), or 672249240 in Unix time (Wikipedia). This corresponds to the beginning of the D'ni hahr 9647. That specific date and time was not chosen at random; it was "the creation time-stamp of the original HyperCard (Wikipedia) Stack for Myst". All conversion programs trying to convert from one specific date/time to another (including displaying the current D'ni time) should use this date as a conversion for the best accuracy. However, the maximum skew of not using this specific date to perform all conversions is only one second; it is up to the program's author to determine if this is an acceptable level of accuracy for their purposes or not.

Authors of conversion software designed to achieve a very high level of accuracy (more than a second per year or designed for predictions longer than ten years into the past/future) should take into account the fact that time (Wikipedia) is not as repetitive and constant as is often assumed (or rather, time remains constant but everything else is changing so time is adjusted to match everything else). Using a programming language's standard methods of calculating the date/time is not the best idea if complete accuracy is required, as these are often simplified and do not take as much into account as would be needed for a completely accurate prediction. Time zones (Wikipedia) should obviously be taken into account, as should leap days (Wikipedia), but care should be taken to exclude the leap year every century (while still including those happening every 400 years). An internal array should be kept with the currently known leap seconds (Wikipedia), plus a method of extrapolating out into both the past and the future in an attempt to provide a more accurate past plus an attempt at keeping future date predictions accurate. Both the extrapolation calculation and the leap second array should be updated at least every two years, or as new leap seconds are announced to keep the system as accurate as possible. Authors who are interested in extreme accuracy of the current date/time should also include a method of syncing the computer's time with a local NTP (Wikipedia) server (preferably NTP over TCP as it better accommodates latency through the Internet), or instructions on how to sync the time manually, ensuring a completely accurate representation of the current D'ni time. Also note that Win9x-based operating systems are only capable of changing the time to the nearest second, so any Win9x-based operating system may be up to half a second out either way, even when synchronised.

Various inaccuracies have happened over the years that make figuring out exactly how long ago something happened quite difficult - a century ago time could not be measured more accurately than around one second per week, and leap seconds could not be accurately measured, calculated or predicted before the first atomic clock was created (1955). Ideally, if trying to predict an exact time in the far future or past, the exact conversion should be displayed but a warning piece of text should be displayed indicating that various inaccuracies might apply for which there are either no workarounds or ways to completely accurately account for, or situations where the user would have to manually correct the changes depending on their specific conversion situation (such as leap-seconds, differences between UTC/GMT/TAI, timezone changes, the offset between UK and US datekeeping, switching between Gregorian and Julian calendars, in 1712 Sweden had a February 30th, the "lost" years throughout history, inaccuracies in carbon dating and continental drift).

To go even one step further, as the exact length of a "second" may be redefined or somehow change in the future, a better way is necessary to store the length of a prorahn that is re-creatable without merely relying on comparing it to an arbitrary unit of the passage of time. Under the International System of Units (Wikipedia), the second (Wikipedia) is currently defined as the duration of 9192631770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium-133 (Wikipedia) atom at 0°K. Given we have a 100%-accurate conversion of surface time to D'ni time, multiplying 9192631770 by 1.392857388844137931 gives 12804025083.767865923, so one prorahn can therefore be defined as the duration of 12804025083.767865923 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium-133 atom at 0°K. This is way beyond the level of "normal" accuracy required for almost every conversion possible and is only listed for theoretical purposes to completely accurately describe the length of a prorahn. Anyone requiring more accuracy can extrapolate out more as required from these formulas, but they would first be advised to build a more accurate atomic clock to measure this time passage as accurately as they're calculating (the listed accuracy here is even a few orders of magnitude more accurate than today's most accurate atomic clocks for future-proofing reasons).

[edit] Old Surface seconds to D'ni prorahntee and back

For reference, the common older method that was used to extrapolate out D'ni time is listed below.

  • A solar Earth year is 365 days, 6 hours, 9 minutes and 9 seconds, or a total of 31558149 seconds.
  • A D'ni hahr appears to be 10×29×5×25×25×25 prorahntee, or a total of 22656250 prorahntee.
  • With the debatable assumption that a solar year on the surface (Wikipedia) equals a hahr of the caverns, one could therefore conclude that a prorahn is about 31556925÷22656250=1.39285737931034 times as long as a second. As cited above, it is defined as "equal to about 1.5 seconds", whereas it seems to be much closer to 1.4 seconds instead, but this could merely be an inaccuracy on the DRC's part.

Conversion therefore simply amounts to multiplying or dividing by 1.39291140413793 (or, when such a constant can't be stored, 1.4).

[edit] Surface (Gregorian) years to D'ni hahrtee and back

The first record of which specific surface year roughly corresponds to which specific hahr was in April 1997 with the release of the cake on the Cyan Cam, celebrating the D'ni new year 9654 and announcing the Riven Journals. RAWA has confirmed that this date is correct. The current hahrtee fahrah (15) began in hahr 9375 (15*625), which is known to correspond roughly to surface year 1719. Assuming roughly the same length of years and hahrtee, this makes for a simple formula. To go from a Gregorian surface year to an equivalent D'ni hahrtee, one simply adds 7656. To reverse, one subtracts the same number.

E.g., the year 2007 is roughly equivalent to the hahr 9663, or journal hahr 288 — which we can easily double-check: 2007-288=1719.

[edit] Journal hahrtee to regular D'ni hahrtee and back

To convert from a regular D'ni hahr (in decimal) to their journal notation (also in decimal), a simple integer division by 625 suffices. The examples below will use the hahr 9412, which is the 37th hahr of the 15th hahrtee fahrah.

[edit] Ruby

Using irb, the Interactive Ruby Shell:

9412.divmod(625) => [15, 37]

This gives us an array containing the hahrtee fahrah and the remaining hahr.

And back:

15*625+37 => 9412

[edit] PHP

echo floor(9412/625); 15

This gives us the hahrtee fahrah. As for the remaining hahr:

echo fmod(9412,625); 37

And back:

echo 15*625+37; 9412

Personal tools