Establishing a standard time for the moon is necessary for the new era of lunar exploration:
There's been a resurgence of interest in the moon, now that we're getting closer to re-establishing a foothold on the celestial body. Space agencies and private companies around the world have been scheduling their own lunar missions to take place over the coming years, and it will be quite complicated having to coordinate with each other when they use different time zones. During a meeting at the European Space Agency's ESTEC technology center in the Netherlands last year, space organizations talked about the "importance and urgency of defining a common lunar reference time." In a new announcement, ESA navigation system engineer Pietro Giordano said a "joint international effort is now being launched towards achieving this."
[...] Deciding on and keeping lunar time won't be easy, though, and they will come with a unique set of challenges. As the ESA notes, "accurate navigation demands rigorous timekeeping," which is why one of the topics the international group of space organizations will have to discuss is if there should be a single organization responsible for maintaining the moon's time zone. Further, they'll have to decide whether to keep lunar time synchronized with Earth's or not, because clocks on the moon run faster based on the satellite's position. While they have a lot of factors to consider, whatever they come up with will have to practical for astronauts orbiting or stepping on the lunar surface in the end.
Bernhard Hufenbach, a member of the ESA's Directorate of Human and Robotic Exploration's Moonlight Management Team, said: "This will be quite a challenge on a planetary surface where in the equatorial region each day is 29.5 days long, including freezing fortnight-long lunar nights, with the whole of Earth just a small blue circle in the dark sky. But having established a working time system for the moon, we can go on to do the same for other planetary destinations."
(Score: 4, Insightful) by Anonymous Coward on Saturday March 04, @03:56AM (9 children)
(Score: 3, Informative) by shrewdsheep on Saturday March 04, @01:13PM (3 children)
If you set your clock to UTC, travel to the moon and come back your clock is no longer in sync with UTC. Do you want to readjust continuously or just use your clock and accept it goes out of sync?
(Score: 2, Interesting) by khallow on Saturday March 04, @01:51PM
This. It'll be out of sync with a lunar clock too.
(Score: 4, Insightful) by VLM on Saturday March 04, @04:06PM
All clocks are out of sync with all other clocks if you have high enough precision instruments to compare them.
(Score: 5, Interesting) by Immerman on Saturday March 04, @04:10PM
For stuff where precision matters, you readjust continuously - or more accurately just correct your clocks to count the passage or Earth-time rather than local time. This is already old news at this point.
I think GPS-style navigation systems are the only place where precise time *really* matters though, and time passes differently for GPS satellites, so their clock are all corrected to report the passage of Earth-time rather than local time, otherwise the whole system would rapidly become incredibly inaccurate.
That's not really what's usually meant by "time zone" though - that's usually a human reference point.
(Score: 3, Interesting) by Immerman on Saturday March 04, @05:32PM (3 children)
If they were talking actual time zones (human reference frames)... Both China and the US?
They're both poised to become major players on the moon, and neither is likely to be thrilled at having working hours on the moon be synced to Europe rather than themselves. We could sync to the international date line, then everyone would hate it, which might be the most agreeable solution.
Except it sounds more like they're just looking to establish a standard reference frame for the moon, like UTC is for Earth. Relativity dictates that time passes slightly faster there, so it needs a separate standard reference frame for lunar time if you want off-the-shelf precision clocks from Earth to be able to keep accurate time on the moon.
There's a lot of questions to hammer out if we want everyone to be able to precisely coordinate with each other like they can on Earth - and the time to settle them is *before* there's a lot of infrastructure built up using sixteen different frameworks.
Presumably individual moon bases would actually also have local time zones within Lunar Standard Time to synchronize working hours with those of their Earthside sponsors - e.g. Chinese Lunar Time might be LST+2.5h. But for human purposes exact time doesn't matter, and I believe you'd only need a few leap-seconds a year to synchronize LST to UTC, assuming you wanted to.
The lunar day is so long that it's probably best to just ignore it for timekeeping purposes... the solar day is going to be more like highly predictable cyclic weather, and there's not a whole lot of benefit to having each month start with the sun in exactly the same spot in the sky.
Or maybe there is - having a lunar month laid out as exactly 30 days per "weather cycle" would make scheduling exploration and power-intensive industry for sunlit times extremely convenient - "The sun rises here on the 3rd of every month, and sets on the 18th" - But doing that would mean having a lunar "day" be only 23.6 hours to be able squeeze an extra half-day into every 29.5 Earth-day lunar cycle.
That would make regularly coordinating with Earth less convenient, as days would drift completely out of sync and workers on the two worlds would only have a shared "noon" once every two months... but it also means that no place on Earth would be getting preferential consideration. And nothing says early moon bases can't be run on Earth time, they just need a standard reference for coordinating times with other moon-based projects.
It'd also be back to breaking compatibility with off the shelf Earth clocks again - at least any that care about time of day, but as long as you have established a standard mathematical formula to convert between UTC and LST it something that most software should be able to easily incorporate that time. It may take a while before Excel formulas and outlet timers understand that not all days have 24 hours in them, but that's a modification that anyone who wants to do business off-world will eventually have to integrate. Might be best to get the ball rolling right out of the gate - supporting the first "non-terrestrial" day length will be the most difficult.
(Score: 0) by Anonymous Coward on Saturday March 04, @10:25PM
We should move the prime meridian there, along with UTC, then do 360 degree longitudes.
(Score: 2) by deimtee on Sunday March 05, @12:16AM (1 child)
My natural sleep cycle is about 25 or 26 hours. I'd go the other way and make the lunar month 28 days of just over 25 hours.
No problem is insoluble, but at Ksp = 2.943×10−25 Mercury Sulphide comes close.
(Score: 3, Interesting) by Immerman on Sunday March 05, @07:41PM
I believe most people's is, when deprived of time-of-day queues for a few days.
I suspect though that there's a reason that our internal clocks are designed to run slow and be continuously reset by external cues (mostly bright light to the eyes or back of the knees), and would hesitate to push those boundaries too much without a good reason.
Could go with 29 days though - the same ~24 minute difference as 30 days, but longer instead of shorter. That's a less jarring difference, and makes for almost an extra half hour of personal time every day, assuming the same length of work day.
And really, having weeks not line up perfectly with the months means that your weekends would slowly migrate through the full lunar day, so you'd get to e.g. enjoy the sunrise on the weekend 2 months out of 7, get the perfect lighting for exploring ____, etc.
Of course there's something to be said for doing away with a work-week entirely. With no natural days, and a month cycle that's going to have a dramatic effect on heavy industry and exploration, there's much to be said for establishing standardized monthly work shifts so that commerce can be maintained continuously, while workers can easily coordinate multiple employers. E.g. maybe the molten regolith refineries hire a bunch of extra people just for the sunrise shifts every month to ramp up production, and those people work those shifts every month, but have completely different jobs the rest of the month. That's a lot simpler for everyone if the month is broken up into standard 2- or 3-day shift-blocks that every employer respects. With 6 4-hour shifts a day and 3 days per block, full-time employment (40h/week) would translate to working 14-15 of the 60 available shifts each month, and if working a few shifts at 2-3 different jobs is normal that opens up a whole lot of room for personal flexibility as well - you can add or drop shifts (12 hours) per month to fine-tune your desired schedule.
(Score: 3, Touché) by bloodnok on Saturday March 04, @06:03PM
https://en.wikipedia.org/wiki/Not_invented_here/ [wikipedia.org]
__
The Major
(Score: 4, Funny) by Barenflimski on Saturday March 04, @04:59AM (3 children)
Imagine you're on the moon, and your day is driven by the idiots on earth? wtf.
(Score: 1) by khallow on Saturday March 04, @01:52PM (1 child)
(Score: 3, Insightful) by Immerman on Saturday March 04, @06:03PM
Yeah, I would assume early lunar bases would probably operate on Earth hours, and I think time dilation should only need a few leap seconds a year for correction.
There's a calendar related issue that's going to need to be settled though - a lunar month is in most respects functionally its natural year, and there's much to be said for a lunar calendar that respects that, assigning either 29 or 30 calendar days per month so that, e.g., "the sun always rises here on the 7th and sets on the 22nd".
But that means having days that are slightly longer or shorter than Earth days. By less than 2%, but that's enough that locations on Earth and the Moon would flip to 12-hours out of phase and back again over the course of every two months. Which could be a nuisance, though maybe not so bad if you assume the moonbase works continuous shifts, which would be reasonable with constant sunlight or darkness throughout the day, and vacuum powered sound insulation between residential habitats synchronized to different shifts.
Introducing an official non-terrestrial day length time zone for the moon would also give software designers a concrete alternate reference frame to support. It's going to be a while before there's much demand for spreadsheets and smartphone calendars that natively understand that not all days have 24 hours, and that time passes at different rates in some time zones than others, but with the formulas laid out developers can start adding support for that especially difficult first "anomalous time", and hopefully there'll be some compliant options by the time a lot of people start wanting them.
(Score: 3, Funny) by bzipitidoo on Saturday March 04, @05:13PM
(Score: 2, Funny) by Anonymous Coward on Saturday March 04, @10:37AM (5 children)
Everyone who has ever been to the Moon has used U.S. Central Time (Houston Time). Why change note?
(Posted specifically to piss off non-Americans.)
(Score: 2) by looorg on Saturday March 04, @01:36PM (3 children)
(as a non-american) Not really pissed off about it at all. It kind of makes sense. After all we already known Americans, even scientists, have a lot of problems converting things to metric and other scales so adding or subtracting hours of the day can get complicated.
That said it does sort of make sense to be running on the same scale or time zone as the people that are running the mission on Earth, or I guess earth people could be on "space time" to. Perhaps it's more important to try and solve/cut the communication delay then giving the moon their own time zone. It's hard to have proper communications when the communications lag could be anything from like 4-5 minutes up to almost an almost half an hour for a one-way message, double if you want a response and it's sent promptly and they don't have to have a think about it first.
(Score: 1, Funny) by Anonymous Coward on Saturday March 04, @03:25PM (2 children)
I wasn't aware that the rest of the world was using metric time.
(Score: 2) by looorg on Saturday March 04, @04:43PM
You don't know what you are missing out on. Technically I guess in some sense we are all using metric time, we just don't tend to talk about it since it's measured in seconds and it gets a bit convoluted to talk about it in normal every day usage.
(Score: 2) by turgid on Sunday March 05, @12:56PM
The French invented decimal time [wikipedia.org].
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by Freeman on Monday March 06, @05:38PM
The most realistic way to run "Moon Time" is to set it to whatever the Earth Time-Zone is for whomever is operating the base. In the event that Houston is the main contact point for American bases, then make that the Time Zone for that base. Assuming any other nations, then set the Time Zone of their Lunar base to whatever country/city Time Zone for them. It's the most sensible solution for humans.
Now, in the event that they want some X weirdness for Lunar Time, then I'm sure that it will be dealt with. Probably in the most obtuse fashion possible.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 5, Informative) by turgid on Saturday March 04, @12:08PM (10 children)
As viewed from the Moon, clocks on Earth run slower because the Earth's gravitational field is stronger than the Moon's. That means clocks on the Moon appear to run faster. This is quite measurable with atomic clocks. In fact GPS satellites and the like have to be able to measure time this accurately.
It's an interesting issue.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 5, Interesting) by pTamok on Saturday March 04, @12:48PM
In fact, there are two different problems here: determining which reference frame to use for atomic clocks to generate lunar time and managing that time - will the BIPM take it on? The other problem is managing lunar civil time and generating a calendar and timezone compatible in some way with the Earth's.
(Score: 1) by khallow on Saturday March 04, @01:54PM (8 children)
(Score: 3, Insightful) by Immerman on Saturday March 04, @06:16PM (7 children)
If you want to get that precise then the monthly change in the moon's distance is going to have a much larger effect.
The moon is so far away that the near side is only about 0.9% closer than the far side, while over the course of the month the moon's distance from Earth changes by about 11%
It's also so far away that it's already outside of most of Earth's gravity well - I suspect that the differences in time dilation would be comparable to those on the surface of Earth due to altitude and gravitational anomalies.
(Score: 1) by khallow on Tuesday March 07, @01:43PM (6 children)
(Score: 2) by Immerman on Tuesday March 07, @03:46PM (5 children)
Except keeping IAT means that you need specially re-calibrated atomic clocks to keep accurate time on the moon... and that wouldn't be a simple task if you're accounting for the continuously varying relativistic effects. It's far more convenient if you just say that "off-the shelf" atomic clocks from Earth will work correctly on the moon, or anywhere else. For which we need to define a time zone in which those clocks continue to keep accurate time. It'll have to be an average, perhaps as measured at some specific point on the moon, but the same is true for Earth - time passes more slowly on the sides facing the sun or moon, and slowest of all directly under a solar eclipse while in a deep cave above a gravitational anomaly.
If the variation of relativistic effects from different locations on the moon is enough to be noticeable, then you add more time zones. Once you've established the conventions for one relativistic time zone, adding additional zones is easy. We've got over 24 time zones on Earth, why should the moon be limited to one?
Besides which, as we go beyond the moon we'll have to start dealing more with velocity-based time dilation as well, which yields mutually contradictory results (e.g. both twins see the other aging slower). May as well rip the bandage off now and establish a sane agreed-upon convention that will be easy to expand to other locations *before* we've built any serious infrastructure based on incompatible conventions.
Maybe we want to call them something else since the math is so much more complicated... but from a daily usage perspective time zones are pretty much exactly what you want. Everyone keeps time locally, and you've got a convention to accurately transform time coordinates from one zone to another.
And frankly, for most usage within the solar system (excel spreadsheets, etc) the math could probably be simplified by only acknowledging relativity in the form of a few leap-seconds per year when translating between time zones. You just need to agree on a convention for exactly how many to add, and when.
You do need more accurate timekeeping for coordinating scientific observations - but so long as you know which zone a time was measured in you can dig up all the data and calculate all the necessary relativistic corrections needed to perfectly translate it to any other zone.
You're going to have to do that at some stage regardless. Makes a lot more sense to postpone all that work for the rare occasions you actually need it, rather than trying to continuously correct every clock in the solar system to a completely different reference frame.
(Score: 2) by turgid on Tuesday March 07, @06:35PM (4 children)
The thing is, those clocks keep accurate time whatever time zone they are in. The time on those clocks really is the time for the local observer.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by Immerman on Tuesday March 07, @08:01PM (3 children)
Exactly.
Which is why you don't want to use UTC on the moon - UTC is measured in Earth's reference frame, so the length of a second is different as seen from either location.
It's basically a bookkeeping issue - to accurately record *when* an event occurred you need to also indicate (or at least imply) *where* it occurred - e.g. 2am in New York does not happen at the same time as 2am in Beijing.
If you don't want to use time zones on Earth you can just use UTC to avoid the issue entirely... but you can't do that with places off Earth because UTC seconds are a different length than local seconds. Which means that to accurately record a time you need either a well-defined local time zone, or to calculate the current UTC time every time you want to record the time of an event.
A local time zone is a far simpler option.
(Score: 1) by khallow on Tuesday March 07, @11:20PM (2 children)
(Score: 2) by Immerman on Wednesday March 08, @05:07PM (1 child)
That'd be a really good start, but what about velocity based time dilation? Someone at that theoretical maximum time speed will still have their time be almost stopped from the perspective of someone they're passing at nearly light speed.
Without a preferred reference frame it's really not possible to establish a non-arbitrary "absolute" time scale. Not to mention you need to actually be able to synchronize to an atomic clock running in that preferred frame for it to do you any good - the whole point of a well defined reference time is to correct for the inevitable drift of every other clock in the universe. And the shipping rates to deep intergalactic voids are... astronomical.
If you don't like time zones, what would you propose as an alternative?
Keeping in mind that the key features are:
- Local atomic clocks must be able to record high-accuracy times in a format that can be translated to any other reference frame
- The notation must be easy for humans to use to avoid misinterpreting times as coming from the wrong reference frame.
- one of the big uses will be digging through archived scientific data years or decades after it's recorded, to see if a recently noticed anomaly manifests in other data sets.
(Score: 1) by khallow on Thursday March 09, @01:14AM
The locals do their own thing? Still seems a poor case for any time zone other than using an Earth-side one like UTC or wherever their headquarters's time zone is.
This is way beyond what a time zone can fix. A time scale is different from a reference time frame. You can do all kinds of things that slow your reference frame clock speed down, but you can't do much to speed it up.
(Score: 4, Interesting) by VLM on Saturday March 04, @04:21PM (1 child)
What's going on is the classic early days of a software project where multiple groups are doing the same thing and having the "best" standard doesn't matter if you can't ship and what matters is what ships.
So NASA and the ESA have semi-incompatible home grown more or less independent combined GPS/TDRS comsat infrastructure projects. "Who's shipping more vs who's more vaporware" is honestly pretty unclear to me although it seems LunaNet is pretty far ahead compared to Moonlight.
So this is the usual office politics style appeal to authority to make their system the official system. If they were far enough ahead in shipping working stuff then everyone would just use it because its so far ahead LOL. I postulate that an appeal to nationalist politics by trying to make project Moonlight the "official" system is darn near proof its failing as a project and the system that'll actually be used by hardware on the ground (on the lune?) will almost certainly be NASA's LunaNet system. Why would they do an appeal to politics if they were not dramatically far behind NASA's system? If Moonlight were successful, well, they'd just go on being successful not playing political games.
LunaNet has a RFC-like interop guide which I downloaded and skimmed. I think EE telecom stuff is cool and I think navsat and GPS is cool so I found the interop guide interesting. The project that's probably going to be successful based on behavior is obviously LunaNet so I read up on it, pretty cool.
Remember a lot of design choices were made for GPS because cold war / military needs / 70s era tech, so "F it we'll make a 2010s redesign for the moon instead of just shipping GPS to the moon" is interesting to compare.
(Score: 3, Insightful) by Immerman on Saturday March 04, @06:20PM
At this point the biggest value might be in making sure everyone is aware that there will *eventually* be a single standard they're expected to comply with, and their software/hardware better be able to be updated when the time comes.
(Score: 2) by Tork on Sunday March 05, @11:51PM
I always thought that stardate was just a sort of cosmetic detail to sound more sci-fi'ish. Maybe it was, but it really would cut through a lot of calendar-related issues. I wonder if we're seeing the beginning of the creation of that concept.
Slashdolt Logic: "25 year old jokes about sharks and lasers are +5, Funny." 💩