Introduction To Stardates

What Do We Know About Stardates?

The “Writer/Director’s Guide” for “Star Trek II”, said this about stardates:

“We invented ‘Stardate’ to avoid continually mentioning Star Trek’s century (actually, two or three hundred years from now), and getting into arguments about whether this or that would have developed by then. Pick any combination of four numbers plus a percentage point, use it as your story’s stardate. For example, 1313.5 is twelve o’clock noon of one day and 1314.5 would be noon of the next day. Each percentage point is roughly equivalent to one-tenth of one day. The progression of stardates in your script should remain constant but don’t worry about whether or not there is a progression from other scripts. Stardates are a mathematical formula which varies depending on location in the galaxy, velocity of travel, and other factors, can vary widely from episode to episode.” (Transcribed from page 99 of “Star Trek Phase II” by Judith and Garfield Reeves-Stevens. Published by Pocket Books in 1997.)

Page 13 of the “Star Trek: The Next Generation Writer’s/Director’s Guide” of March 23, 1987 had this to say on the subject:

“A stardate is a five-digit number followed by a decimal point and one more digit. Example: ‘41254.7.’ The first two digits of the stardate are always ‘41.’ The 4 stands for 24th century, the 1 indicates first season. The additional three leading digits will progress unevenly during the course of the season from 000 to 999. The digit following the decimal point is generally regarded as a day counter.”

According to the Memory Alpha website, this was later revised to:

“A Stardate is a five-digit number followed by a decimal point and one more digit. Example: ‘46254.7.’ The first two digits of the Stardate are ‘46.’ The 4 stands for the 24th Century, the 6 indicates sixth season. The following three digits will progress consecutively during the course of the season from 000 to 999. The digit following the decimal point counts tenths of a day. Stardate 45254.5, therefore, represents the noon hour on the 254th ‘day’ of the fifth season. Because Stardates in the 24th Century are based on a complex mathematical formula, a precise correlation to Earth-based dating systems is not possible.”

(I’ve corrected what seems to be a small typo: S.D. 45254.4 is given in the original quote, but if it’s noon, then the stardate should be 45254.5, surely?)

Naturally, to these brief explanations, we can add all the stardates used in “Star Trek”.

From this evidence, we can identify some basic requirements for a stardating system:

1. The base unit is approximately a day.
2. “1,000” units is approximately one year.
3. Stardates should vary by more than just the passage of time.

We can also add two further, implied, conditions:

4. The system should accommodate as many of the stardates used on-screen as possible. (Although this is never going to be 100%. Real stardates don’t have an underlying system.)
5. The system should have some practical value as an alternative to standard dates. Otherwise, why change?

Point 5 is always going to be a matter of opinion rather than fact, but it still needs to be considered.

Some Ideas can be Ruled Out

In “Appendix I: Regarding Stardates” on page 299 of the “Star Trek Chronology” by Michael and Denise Okuda (the 2nd edition, published by Pocket Books in 1996), it is suggested that relativistic effects account for the difference between the actual 1,000 day length of 1,000 stardate units and the observed length of about one year per 1,000 units. This idea isn’t theoretically impossible, but it doesn’t match up with what we see. Wesley Crusher does not age more rapidly than his friends on Enterprise when he attends Starfleet Academy, and time does not pass more slowly as measured by the progress of stardates on the non-moving space station in “Star Trek: Deep Space Nine”. Indeed, there is no large scale relativistic effect ever visible in “Star Trek”. Time appears to pass at exactly the same rate whether you’re moving at warp speed or not.

It would be possible to balance the “one day/one year” imbalance by having a stardate that counts in years for its first three digits, but then shifts to days for the last two. This has the huge disadvantage of creating “impossible” dates. For example, if we start at S.D. 00000.0, and progress evenly forward, S.D. 00036.0 will be followed by S.D. 00137.0. That might be acceptable working from scratch, but there are already stardates we need to work backwards from, and they don’t support this idea. In the example above, what happens when something occurs on S.D. 00040.0, or S.D. 00102.0? Those dates just can’t exist. To a degree, this is a “straw man” argument, since there haven’t been any serious attempts to create a system of stardates like this, but I wanted to rule it out. Whilst a 365.25 and 1 day “split” represents something of an extreme, the basic problem will affect any attempt at “sliding” stardates.

The “Star Trek II” explanation of stardates suggests that stardates might vary wildly from location to location. To a degree, that option is severely curtailed by the later “Star Trek: The Next Generation” explanation of stardates, but it still has to be examined. Maybe the stardate varies hugely and almost randomly depending on where you are? Unfortunately, that has a serious flaw: why use them? It’s established that the people on starships know whether it’s Thanksgiving, or Diwali, or their birthdays, so why use a system that has no rhyme or reason when they could as easily just say it’s Tuesday the 15th? Self-evidently, a stardate fixes the time as acceptably as our current calendar for the people using them.

Am I sure that point 1 is vital? After all, no-one ever specifically says that one stardate unit is one day. It might be one thousandth of a year? That would solve the “split” problem. It would also make the base unit of stardates just less than 8 hours and 46 minutes long. This has three flaws: first, the scriptwriters were guided by the writer’s guides. Even though it’s not spelled out, the stardates progress too slowly for units lasting less than nine hours to be plausible. Often, the stardates are a very useful guide to the internal chronology of a story, but that only works if you assume they are based on something very close to a 24 hour unit, as I have discovered. Second, how is 8 hours 45 minutes and 36 seconds a sensible unit of time? The base unit of time is the second. This gives us a stardate unit of 31,536 seconds. I admit I’m exaggerating for effect, but even if you explain it as the subdivision of the light year as a base unit of time-space measurement, it all seems a bit unlikely. Especially since the two time-keeping systems of stardates and the “Terran Old Calendar” exist side-by-side so comfortably, I would argue that the base unit of stardates is something more user-friendly. Third, what about leap years? Do the stardates become longer and shorter depending on what kind of year it is? In that case, the arrangement becomes more confusing than reasonable, as far as I can see.

So Where Do I Go?

First, we need to see how long 1,000 stardates really is. Yes, it’s approximately a year, but what is the on-screen evidence? In the “Star Trek: Voyager” episode VOY “Timeless,” Captain Janeway is absolutely specific that the ship has been trapped in the Delta Quadrant for four years, two months and eleven days. Quite soon after, she makes a log entry for S.D. 51243.6. Since VOY “Caretaker” is dated S.D. 48315.6, we can make a very rough guess at how many stardate units there are per day. If 3,828 stardate units pass in about 1,532 days, then 1,000 stardate units will be the same as 400.21 days. Making some slightly more elaborate assumptions about dates, VOY “Homestead” begins with the celebration of the 315th anniversary of First Contact, fixing the date in our calendar as 5th April, 2378, and the show is stardated 54868.6. Earlier, TNG “Data’s Day” was placed on the Hindu Festival of Lights, known as Diwali or Deepavali. The most likely day that’s being referred to is the 3rd November 2366, which corresponds to S.D. 44390.1. If this line of reasoning holds up, then 4,171 days is very approximately 10,478.5 stardate units. I think it’s coincidence more than anything else, but that means that 1,000 stardate units is 398.1 days by this calculation. In DS9 “Second Sight” Commander Sisko says that it is the day after the fourth anniversary of the Battle of Wolf 359. If it’s S.D. 47329.4 and the battle was around S.D. 44000, then 3329.4 stardate units will be around 1,462 days. That gives 1,000 stardate units as 439.1 days, which is not very close, but closer to 400 days per 1,000 stardate units than 365 days would be.

Not So Fast!

Unfortunately, this evidence is hardly conclusive. Other “fixed” points give different results, and I’m basically ignoring a very big elephant in the room. The “Star Trek Chronology” placed all of the stardates for each season of “Star Trek” in an individual calendar year. Thus, all of the “41XXX” stardates were assigned to the year 2364, all of the “42XXX” ones were placed in 2365, and so on. For all my carping about it, 1,000 stardates, at least as far as that book is concerned, are equal to a year. That’s the closest to an “official” interpretation there is, and it’s influenced a lot of stardate choices over the years. I can decide not to include “Star Trek” books, comics, games, computer programs, animated shows or audio adventures in my timeline, but is it a good idea to adopt a system that is completely incompatible with them all? I became very attached to a system that used a standard 24-hour day as the base unit of stardates. It even worked, after a fashion. I had a lot more time available to fit things into, and it hit easily as many of the data points (within the run of the series, anyway) as anything else I’d tried. But it left me with a lot of niggling problems (all attempts at a stardating system will do that) and one big one: the reset points. Every once in a while, the system needed to be re-zeroed to keep it on track. I’d got it down to four, but they were arbitrary. Yes, they solved some problems that are otherwise impossible to avoid, but was that enough? Especially when setting the value of 1,000 stardate units to a year doesn’t need any resets at all. It’s been pointed out by a number of people over the years, but I recently read a very forceful forum post by Graham Kennedy that put the idea back into my head. By “rolling” the stardates around to zero, you can count back from “Star Trek: The Next Generation” and arrive at “Star Trek” in the 2260s. More to the point, TOS “Space Seed” falls almost exactly 15 years before “Star Trek II: The Wrath of Khan”, just like the people in the film say it’s supposed to. Yes, there are problems, but it’s simple, and it doesn’t require a lot of fudging and special pleading. I tried to be as ingenious as I could, but there’s no getting round the point that if stardates need to be recalibrated, why not every other calendar? So I gave the idea another go, and was very surprised at the results I got. Of course, I still have the problem that a stardate unit of one-thousandth of a year just doesn’t fit with the way stardates seem to be used.

You’re Stuck!

Yes I was, and for quite a long time. Then I began to look at the pattern of stardates. The first three digits progress quite regularly from the start of a season to the end. The last digit has to be the same as a day. But what about that second to last one? Let’s take a look at the last season of “Star Trek: The Next Generation”, in production order:

Episode Title Stardate
Descent, Part II 47025.4
Liaisons -
Interface 47215.5
Gambit, Part I 47135.2
Gambit, Part II 47160.1
Phantasms 47225.7
Dark Page 47254.1
Attached 47304.2
Force of Nature 47310.2
Inheritance 47410.2
Parallels 47391.2
The Pegasus 47457.1
Homeward 47423.9
Sub Rosa -
Lower Decks 47566.7
Thine Own Self 47611.2
Masks 47615.2
Eye of the Beholder 47622.1
Genesis 47653.2
Journey’s End 47751.2
Firstborn 47779.4
Bloodlines 47829.1
Emergence 47869.2
Pre-emptive Strike 47941.7
All Good Things… 47988.0

That number is a lot less regular, and the irregularity extends right into the shows themselves. To take a completely separate example, in TOS “And The Children Shall Lead,” Professor Starnes makes his last log entry on S.D. 5038.3. Enterprise arrives just too late on S.D. 5029.5, and they discover his body where it fell. What if that’s not a problem with stardates, but the key?

My Solution

Particularly after the re-mastered version of “Star Trek: The Next Generation” began “fixing” mistakes and making things that had previously been illegible easy to read, stardates have to have a basic unit exactly 24 hours long, but they also incorporate data based on other factors. This data is encoded in the last two digits before the decimal point in a stardate. How this data is encoded is something that requires an understanding of how space and time work. Naturally, since we currently don’t understand how anything can move faster than the speed of light, or have any direct evidence of any other dimensions than three of space and one of time, we can’t know how it works, just that it does. The practical result is that stardates progress quite regularly in 1 unit increments, and in 30- and 40-unit increments. The disconnect comes in-between. Once you start interpreting stardates in this way, it becomes possible to effectively convert nearly all, rather than hardly any, of the later stardates. The internal chronologies of the stories begin to make sense, and stardates become a useful guide instead of a frustrating mystery.

That’s Easy for You to Say

It’s easy to introduce a massive fudge factor into stardates and then wave your hands and say “solved!”, but why do it like that? Yes, it ticks the box of the dates being based on more than just time, but why that way? Isn’t it confusing? Would it work, and how would it work? The first thing to point out is that someone actually using stardates would find it less confusing. S.D. XXXX3 would follow S.D. XXXX2, and in turn be succeeded by S.D. XXXX4. There would never be any gaps or jumps, and the other numbers would just be there. Even if you were trying to “guess” a date, there could only be a maximum of four specific dates to choose. Selecting a “mid-value” would mean that you’d be at most 20 units (or 20 days) out. It might not seem as precise as our calendar, but our calendar doesn’t have extra data built in, so in fact I’m arguing that it’s actually more precise but in a different way, and worth switching to.

Yes, but how can having different numbers represent the same day, and the same number representing different days possibly be a good idea? Again, the “fuzziness” around dates can be overemphasised. We’re not used to it, but that doesn’t make it impossible. Stardates may well be used to fix a “probability” of being in a certain place and time. Given the number of digits available, that’s never going to be incredibly precise, but it could be useful to an organisation like Starfleet.

Even if it’s impossible to understand exactly how stardates work, I need to explore what it is they do. My previous guess at this became very tied up with a specific “space-time correction factor” and I ran into problems when it became obvious that stardates would only work with 30- and 40-day “months.”

The latest version of stardates replaces the “correction factor” with a grid of possible dates, running from 00 to 99 in each month:

Calendar1a.png

The shorter months do have more options for each day, but I would guess that the 100 available days for each month are only a rough approximation to something that can vary to a much greater degree. In theory, all of the options are as “real” as each other, but I needed to keep track of what I was doing. For that reason, the 30-day “months” use the letters x, y and z to keep track of how far into the month a particular stardate is, and the 40-day “months” use a, b, c and d in a similar way. The stardate generator puts a random number into the date, replicating a process that since I have no idea how it works, can’t be other than random.

Jason W. Hinson has written quite an elaborate theoretical background for warp physics, available at http://www.physicsguy.com/ftl/index.html. I don’t pretend to understand all (OK, that should really be “I understand practically nothing”) of it, but he seems to be arguing that a lot of the problems with having speeds faster than light could be solved by assuming a “Newtonian universal time” operating alongside “Einsteinian relative time”. Perhaps it is the difference between these values that’s being measured. Some sort of co-ordinates in space are extremely unlikely, and you have to bear in mind that whatever it is, there are no “extra” numbers to be added to the stardate. Naturally, extra detail could be encoded separately, but it can’t be essential to the whole thing, because that’s not how stardates are used. Another possibility could be that the “extra” element to stardates keeps track of particular “world lines.” Since that’s a concept that exists in real physics, I don’t think that it’ll mesh very well with the range of dates I have. Maybe it’s a whole range of values, mushed together and simplified. All I can say with certainty is that I don’t see any obvious pattern to it.

Originally, I assumed that stardates might behave differently on stationary planets and moving starships. Having now fitted as many stardates as I can into a timeline, I can say with certainty: the variation is random. In practice, it is often the case that stardates will progress arithmetically during a story, and then change wildly “off-screen,” before the next story begins. Unfortunately, that seems to be just the way it is. It also seems to change in sudden leaps, rather than slow drifts, so whatever is being measured changes rapidly and randomly. Of course, it’s possible that Deep Space 9 is not a good example of a stationary installation, being close to a wormhole. It is worth bearing in mind that the example mentioned earlier for TOS “And The Children Shall Lead” and the stardates for DS9 “A Man Alone” do support the possibility that stardates can be different for the people on a planet or space station and the people arriving in a starship. My own opinion is that if there’s any sense at all to stardates, then “stationary” stardates should change less rapidly than “moving” ones. Put simply, if you’re at a planet, they should progress fairly regularly; if you’re travelling at warp, they should be all over the place. This won’t match up to the “screen-used” stardates all the time, but saying that it’s some kind of uncertainty measure that only changes when the audience aren’t looking doesn’t appeal to me at all. I would argue that this isn’t a problem that I’ve made by choosing a particular solution. The instructions to writers quoted at the top of the page set this up, and there’s no easy way to avoid it.

In the end, all I can say is that it’s the only solution I can come up with that comes even close to working.

It may seem that predicting a stardate is next to impossible, but remember that Starfleet calculates these things. Ordering a starship to a certain stardate could easily be sending it to a location as well as a time, although a rendezvous between two ships needn’t necessarily be at the same stardate for both of them. The first three digits and the last, and the decimal places, would match exactly, though.

Finally, bear in mind that stardates haven’t replaced conventional dates except in certain circumstances. Both have a place in the lives of the people in “Star Trek”, and that’s an important bit of evidence in itself.

So now I’ve decided on a system, how do I implement it?


Stardates
Calibrating Stardates

by StrauchiusStrauchius on 26 Mar 2011 21:41, last updated on 09 Jul 2017 09:23