Is anyone aware of a date/time representation system that would work universally (including extraterrestrial places)?
I just have been curious about this question for long. Sure, we could keep an earth referential on a moon base, but then what about Mars?
As a software developer it is already difficult to always get dates/times properly with timezones, now imagine places which does not have 24 hours per day or the same weeks/months/years durations...
NASA has actually thought through this problem and created SPICE, which lets you convert between different time systems, some relativistic and some not, as well as doing conversions between various reference frames: https://naif.jpl.nasa.gov/naif/index.html
SPICE is pretty awesome. I wish that more people in the aerospace industry were aware of, including people AT NASA. I work at a company contracting on NASA projects and a couple weeks ago I had to correct their code because they weren't accounting for the leap second offset between UTC and GPS correctly. When I asked why he wrote his own function instead of using SPICE he responded "what's SPICE?". Literally people in the same building as him maintain the SPICE toolkits.
Need to bring back some of those brownbag lunch & learn events, starting with "SPICE up your clocks"! Except people might not be comfortable sitting in the same room these days
Comfort won't be much of a factor since most NASA centers are completely work from home for non-mission-critical work for the indefinite future. Nonetheless, we do have a ton of these kinds of things going on all the time. The bigger problem is that NASA's culture is so meeting heavy that it's hard to justify these kinds of low importance events on my calendar.
> The bigger problem is that NASA's culture is so meeting heavy that it's hard to justify these kinds of low importance events on my calendar.
Not sure if you are speaking from experience, but if that is the case, and this is true, then NASA as an organization seems to be a poor judge of what's important.
Yes, from experience. It's not that we don't know what's important, it's that it's all important and I have to find time to actually write code every now and then too. The real problem is just that we're all very busy and it's not really possible for everyone in the agency to have even a cursory awareness of everything that's going on.
Even now with everything being virtual, I get invites to brown-bag type events probably 3-4 time per week. I can go to one or two, but there's no way I can fit every single one into my schedule.
There are a couple of issues at play. One is that there's so much interesting stuff going on that I (and most of my colleagues) tend to volunteer ourselves for lots of projects, which results in us going "deep" on a couple of projects at the expense of not having enough time to go "wide" by attending lots of talks that aren't directly related to our own work. That part's on me and I really could make more time in my schedule if I just said "no" more often (but again, I don't say "yes" because I'm pressured to do so, I say "yes" because the work is really fun and interesting!).
The other question is why we have so many meetings per project. That one's tougher to tackle and I don't really have an answer. The one thing that I have identified is that we're very in to making sure that everyone has their say on things before taking action. That's a good thing overall, but it also leads to tremendous meeting bloat. A meeting that would only take 5 minutes if everyone restricted themselves to discussing critical issues before making a decision regularly takes a full hour in which we examine every pitfall, no matter how minor.
Interesting, it sounds like in this case it's mostly a good problem to have - even ensuring all voices are heard is good, from a sound engineering perspective, which I'd imagine is important for NASA's missions!
I wonder if there would be a benefit in your case if folks had to follow a similar process to the one Amazon requires for its meetings (this may be something NASA already does, but I will admit I'm projecting a bit here and am wishing my organization required some writing before calling for a meeting):
> We don’t do PowerPoint (or any other slide-oriented) presentations at Amazon. Instead, we write narratively structured six-page memos. We silently read one at the beginning of each meeting in a kind of “study hall.” Not surprisingly, the quality of these memos varies widely. Some have the clarity of angels singing. They are brilliant and thoughtful and set up the meeting for high-quality discussion. Sometimes they come in at the other end of the spectrum.
> ...
> Here’s what we’ve figured out. Often, when a memo isn’t great, it’s not the writer’s inability to recognize the high standard, but instead a wrong expectation on scope: they mistakenly believe a high-standards, six-page memo can be written in one or two days or even a few hours, when really it might take a week or more! They’re trying to perfect a handstand in just two weeks, and we’re not coaching them right. The great memos are written and re-written, shared with colleagues who are asked to improve the work, set aside for a couple of days, and then edited again with a fresh mind. They simply can’t be done in a day or two. The key point here is that you can improve results through the simple act of teaching scope – that a great memo probably should take a week or more.
I'm very thankful for the creators of https://www.worldtimebuddy.com/ handling time zone weirdness, etc, so that I can still get to Zoom calls on time (usually). I don't know how the Moment developers can ever think it's "done" - "We now generally consider Moment to be a legacy project in maintenance mode. It is not dead, but it is indeed done."
It depends on which layer you're asking about addressing. You can represent anything non-relatavistic on top of the Unix epoch, and it could be handled as simply as using alternate time zones.
The big problems come from huge Earth assumptions about interval duration and interval sequencing being violated. A lunar day is 29.5 Earth days. Does the lunar calendar use solar days, and just have absurdly long weeks and years? Maybe the years are standard Earth length, they just don't use weeks or months. Does a lunar society have a shorter "not-day" that replaces the way Earth uses days, and now everything needs to handle this new unit of time? Do days still get measured as solar intervals, and we just decide it's okay for days to be longer than weeks on the moon, so it stays Tuesday for a month at a time?
Off earth you have a launch criterion and accumulated subjective seconds. That's your onboard time.
There are no days, weeks, months, years. Just count the seconds and make sure everyone knows the epoch you started at.
Now, let's suppose you have a permanent settled outpost on Luna. You still use accumulated seconds as your time basis, but for casual conversation, you can talk about any Earth time marking that makes sense to you -- next Tuesday, or March 20th, or "in three months". You might occasionally care about whether it's bright or dark outside, but the tidal lock means that local weeks and months really aren't useful.
The hard thing is when you actually care about both the time on Earth and the local time/date/season of a planet you are interacting with naturally. Let's hypothesize a terraformed Venus, and while we're at it, let's change the axial tilt from 2.mumble degrees to 24 degrees. That gives us a 224ish terrestrial day V-year, a 1.92 V-day V-year, and approximately eight seasons per V-year, each being 56 days long.
On that planet, you get to go outside and enjoy the fresh air, but you want to know what season it is more than you want to know what month it is:
dark-winter, dark-fall, dark-summer, dark-spring
bright-winter, bright-fall, hell, bright-spring
(Venus rotates backwards, that's why the seasons are all funny.)
But when you want to know when the next shipment of Earth whisky is coming, you ask a computer.
Mission elapsed time just complicates things. Now that we have enough memory that we don't need to worry so much about overflow, we just use the Unix epoch even onboard spacecraft.
Unix time is not really great for any scientific purpose; it defines each day to have exactly 86400 seconds. (So, eventually you have problems with leap seconds.)
UTC is better, because at least it is aware of leap seconds, but performing any calculation spanning a year's end involves consulting a database of leap seconds. Notably these aren't determined much in advance, so such calculations involving future dates will also involve leap-second errors.
TAI is best (for non-relativistic non-sidereal purposes), as it is not adjusted to account for leap seconds. You can calculate with it without trouble.
(All three of the above are based on the atomic SI second, so despite their differences, their seconds tick synchronously.)
In astronomical contexts there are good alternatives to the epoch (like TDB, mentioned in another comment). I interpreted the top-level question as relating to day-to-day measurements and representations of time, presumably for use by extraterrestrial humans, since the commenter asked in the context of handling time zones and units like weeks and months which are irrelevant in a scientific context.
UTC is not a great choice for a universal interplanetary time system, as it's designed to work on just one planet, for just one calendar system. It'll work fine while we're asking humans on Earth to oversee robots on the Mars, but will fall down pretty quickly once humans take permanent residence on celestial bodies that don't have Earth's rhythms.
Well, the general idea seems usable enough; X time units from a specific reference point. Conversion is then done to whatever local time-keeping system you might have.
Leap seconds are based on conditions here on Earth and wouldn't really be needed on Mars or Venus. They might have different peculiarities though, and they wouldn't be usable on Earth. In that situation, a single point of reference would be useful for conversions.
Right; "X time units from a specific reference point" is what TAI is. Taking Unix time and removing the notion of leap seconds is effectively a circumlocution for exactly that standard :)
Vernor Vinge's A Deepness in the Sky has a bit where a "programmer archaeologist" (a term I just love) notes that deep in the thousand year old code running the starship the time is still counted in seconds since about a megasecond after the first lunar landing.
UTC works just fine, or TAI if you don't want to deal with leap seconds. (UTC is international atomic time (TAI) offset by leap seconds to keep in sync with earth's rotation)
Once you get into relativistic effects you need something better, but for practical purposes UTC and TAI are just fine for the foreseeable future. The days just become a meaningless abstract concept.
Time dilation undoes hopes of making any measure work universally. (Unless you include a bunch of other things besides one number in the measure...) But for subjective time there's UT1 (UTC minus leap seconds).
I just have been curious about this question for long. Sure, we could keep an earth referential on a moon base, but then what about Mars?
As a software developer it is already difficult to always get dates/times properly with timezones, now imagine places which does not have 24 hours per day or the same weeks/months/years durations...