>So synch clocks in different places is meaningless
Then why do we do it?
(I'm not talking techno here, just general concepts. Please forgive me if to 'sync' a clock actually means something more then just calculating what time one person sees vereses another and displaying that as a 'sync-ed' clock.)
>What you *can* do is exchange (speed of light) signals and use thoseto vompare clocks (after applying relativistic corrections forrelative motion
Right, that's what I'm thinking.
>But that doesn't mean that when both places' clocks show a goivendate/time that it's the "same" time
By default, no it doesn't mean that. But there's no reason we can't create a clock that displays the same time as that which our GPS sats "see". The servers we have at my work do not work at all if their clocks are not sync-ed with each other and with our desktops. This does not mean we are displaying that time on our computers, however. We have specific software that let's us set our computers time to whatever we want while keeping them in sync with the main server and any client servers.
For that mater, many of our clients are in different time zones, but our servers are able to talk to them because there is an agreed upon way to measure time. When one of our computers gets out of sync (whic does happen, though not often) it cannot talk to the network.
In the situation where time is passing at a different rate between two places, but people at the two places can talk, they would need to agree which 'time' to use as the baseline in order for their computers to network properly. (But, of course, they don't *have* to network their computers in order to comunicate via radio or any other method that doesn't require networking.)
>Why go to all that trouble? All that matters for a "standard" clockis that it be *consistent*, not the rate it runs at
Yes, but how are you going to get all worlds to agree on the same time? And it's not really much trouble at all as any world could easily do the calculations without the need to send a physical clock to a zero-G environment.
>The time difference between zero-g and any gravity humans can standis a matter of seconds over *years*.
I'm not completely sure about that as it is substancial enough to affect us today, and sats aren't even far enough away from earth to be unafected by our gravity.
>The velocity differences between systems and ships will be a muchlarger value
Hmmmm. If that's the case, there's no real reason to debate this, is there? The clocks will be off one way or another, and since I'm just thinking in terms of generalizations that works for me.
Sent on the TELUS Mobility network with BlackBerry
-----Original Message-----
Date: Fri, 23 Jul 2010 14:27:23
Subject: Re: [Traveller_TNE] speed/acceleration/mass/energy/etc
On 23 Jul 2010 at 14:40, wrote:
> What I'm thinking is that, with so many different worlds, each with
> different levels of gravity, the clocks on each will be out of sync
> with each other. Only slightly, granted, but if the effect is
> pronounced enough that we have to take it into consideration today,
> how much more will we have to take it into consideration in a future
> where a substancial portion of the population lives almost
> exclusively in a zero-G environment?
Ah, you are suffering from a common misconception.
Simultaneity doesn't exist.
So synch clocks in different places is meaningless.
What you *can* do is exchange (speed of light) signals and use those
to vompare clocks (after applying relativistic corrections for
relative motion.
But that doesn't mean that when both places' clocks show a goiven
date/time that it's the "same" time.
Another consequence od relativity.
> What I'm thinking is that, with so many different worlds, each with
> different levels of gravity, the clocks on each will be out of sync with
> each other. Only slightly, granted, but if the effect is pronounced
> enough that we have to take it into consideration today, how much more
> will we have to take it into consideration in a future where a
> substancial portion of the population lives almost exclusively in a
> zero-G environment?
The adjustments are *minor*. We have bigger adjustments to synch
atomic time with the Earths's rotation (look up "leap second").
Since there's *no* way* to get a message between solar systems in
less than a week, and the travel time varies, you don't need that
degree of synch.
> As far as such a setting is concerned I would think the easiest thing
> to do would be to take an atomic clock (or the fututre equivelant)
> out into an area of space which is the least affected by gravity and
> use that as your baseline for a galaxy-wide time system.
Why go to all that trouble? All that matters for a "standard" clock
is that it be *consistent*, not the rate it runs at.
The time difference between zero-g and any gravity humans can stand
is a matter of seconds over *years*.
The velocity differences between systems and ships will be a much
larger value.
>All worlds
> would have their clocks adjusted to this zero-G atomic clock, each
> measuring a second slightly differently with spaceships using the
> zero-G time as their base measurement. A ship's computer would then
> need to adjust all the on-board clocks as the ship approached a
> source of gravity, or even -possibly?- as the ship itself accelerated
> generating artificial gravity. This would likely be especially t
I had to go to a lot of trouble to get the text after where it got
chopped above. Your mail program is ising base-64 encoding for *plain
text*. That's stupid as it results in the text inside the raw message
looking like gibberish, and causes problems when mailers translate it
back to plain text (in my case, lines over a certain length (500?
1000? or so characters) get truncated). That's another problem, while
*in theory* unlimited length lines are ok, in practice, it is
*strongly* recommended that your mail program have a EOL at the end
of each *line* not each *paragraph. With 72-75 characters being the
recommended line length)
> As far as such a setting is concerned I would think the easiest thing to
> do would be to take an atomic clock (or the fututre equivelant) out into
> an area of space which is the least affected by gravity and use that as
> your baseline for a galaxy-wide time system. All worlds would have
> their clocks adjusted to this zero-G atomic clock, each measuring a
> second slightly differently with spaceships using the zero-G time as
> their base measurement. A ship's computer would then need to adjust all
> the on-board clocks as the ship approached a source of gravity, or even
> -possibly?- as the ship itself accelerated generating artificial
> gravity. This would likely be especially true for ships with higher
> acceleration ratings (4G+).
There's "standard" time, and there's "local" time.
There's a stndard second (set by the time atomic clocks keep or
something more accurate) which will get used for a lot of stuff.
Likewise there will be standard minutes, hours, days and yeatrs
(looks like the Imperium doesn't go for weeks or months)
But there's a difference between measuring duration and
clocks/calendars.
Among other things every habitable planet is going to have a *klocal*
clock & calendar. That's because the planet won't rotate in 24 hours,
nor will it take 365 days to go around its star.
Heck, for the Mars landers they have to measure local days in "sols".
I and others have suggested that "day" be reserved for 24 hours,
while "sol" get used for the local solar day.
On Mars the sol is less than an hour longer than a day. But it adds
up to several "days" difference over a month. (ie after 30 days have
passed, you've only had something like 27 sols pass)
Years get even worse, but you need them because the seasons go by the
local year (we'll need a term for the local "year" too. I'm using
"anno").
You don't divide the sol into hours, because the result won't be
even, and with the need for time zones, fractions of an hour get
ugly.
So you need a name for the chunks you break sols into. David Brin
used "dura" and "duras" in the Uplift books. I assume that came from
"duration". I'd been using "peri"/"peris" (pronounced peer-ey, from
"period")
Yopu want to divide the sol into something that's easy to subdivide
for shifts and the like. That's why 12 & 24 are so good for hours.
You can get 2 12-hours shifts, 3 8-hour shifts, 4 6-hour shifts or 6
4-hour watches in a day.
But if you had 10 duras in a sol, you can only break that up into 2
5-dura shifts or 5 2-dura watches without dealing with fractional
units.
So *every planet* is going to have different clocks and calendars.
The Imperial date/time are only used for scheduling stuff between
planets.
Anyway, getting back to trying to keep the Imperial Calendar synched
between systems, there are reasons for the Scout service and others
to set up stations in the outer reaches of some systems and send
modulated lasers links between them. Once there's been time for a
round trip link, they'll have the distance between the stations
figured (based on time codes in the beams, and other things) as well
as the velocity difference. Which is why the ISS does it, to allow
really accurate star surveys.
>From that you can calculate what time it "is" at the other end of the
link (sort of, that no simultaneity bit is a pain). And that will do
for keeping you synched with Imperial Standard time.
But it'll take around 7 years per parsec to synch over one of those
links.
For systems not part of the grid, you'll go with radio signals (like
the time signals on WWV and other stations here on earth, but a *lot*
more powerful).
The transmitters will be insanely powerful and it'dd take fairly
large antennas to pick up the signals. But since they'll be (like
WWV) brodacasting on *very* precise frequencies, you can use the
doppler shift to get a velocity correction, and if you can pick up
more than one you can use the difference in time to help place the
distance, which gives you the correction for "the signal from them
says it was sent on X, so the time here must be Y"
Still, it's going to be uncertaoin.
Merchant skippers will allow for extra time if they have a "must be
delivered by X date/time" contract. Because time between systems is
not exact. (and because time in jump varies uncontrollably)
--
Leonard Erickson (aka shadow)
shadow at shadowgard dot com