> Each rover has its own set of photos stored in the database, which can be queried separately. There are several possible queries that can be made against the API. Photos are organized by the sol (Martian rotation or day) on which they were taken, counting up from the rover's landing date. A photo taken on Curiosity's 1000th Martian sol exploring Mars, for example, will have a sol attribute of 1000. If instead you prefer to search by the Earth date on which a photo was taken, you can do that too.

So when do codebases for `strftime()` functions get extended to deal with extraterrestrial timezones?

Every string-formatting function must have a new prefix of "m" for Mars-safety: msprintf, mstrftime, etc. An extra int argument must be included to indicate whether to format in Martian or Earth sols. Clearly the addition of this new argument will 100% future-proof the API against any other modifications required as humanity expands into space.

Wouldn't it be better to just add an argument for which celestial body the calculation is being performed for? This would be more flexible in the future.

I guess this would work well for other bodies as well, like moons.

...if you look up fast enough, you might just see the tail end of the joke as it passes over your head.

Talking to yourself, there?

Frequently, but it's a bit harder than that. Days on different planets don't have 24 hour durations. Try and adapt that to every date library ever.

I work on display libraries for multiple projects including MSL, and the standard solution is to use "slow seconds" and force Mars days to be 24 hours.

I did ask moment.js how they might support Mars time and didn't get far.

https://github.com/moment/moment/issues/2391

Interesting question. Even NASA can't standardize.

Each lander mission so far has used its own time zone, corresponding to average local solar time at the landing location. Of the six successful Mars landers to date, five employed offsets from local mean solar time (LMST) for the lander site while the sixth (Mars Pathfinder) used local true solar time (LTST).

https://en.wikipedia.org/wiki/Timekeeping_on_Mars#Time_zones

That's pretty straightforward, actually --- just fail, setting errno EABSOLUTETIMEISAMEANINGLESSCONCEPTINGENERALRELATIVITY.

There was a reason why modern C extended the identifier limit, you know.

Actually absolute time SINCE an epoch (event and frame of reference) is meaningful. You can convert between times in different epochs. E.G. if we consider the epoch of a particular event on mars (Curiosity snapped a photo) we could convert that from the IAU_MARS frame of reference into the J2000 reference frame and find the seconds since a significant event, e.g. the TDB reference when the prime meridian first pointed directly at the solar system barycenter in the year 2000.

So those time conversions need to be augmented to understand reference frames in the special case, or continuous reference transitions in the general case. I am sure it will be a gnu extension by 2020.

> Sounds (beta)

> Sound exists in space. Sometimes. And NASA has released a series of space sounds via sound cloud. We have abstracted away some of the hassle in accessing these sounds, so that developers can play with the audio files. For example, a useful application would be an automatic filter to identify human voices in these audio files. For now, that would help identify content. Later, however, when we retrieve sounds from far-off planets, we can apply the filter to identify unknown human space colonies. That was a joke. Sort of.

https://api.nasa.gov/api.html#sounds

The entire document is written in a pretty informal style.

Cool - data sets around Landsat 8, APOD, Near-earth Asteroids, Mars rover photos, the NASA patent library, even historical audio recordings. Hope they keep adding to it!

Wish they had something for the ISS for example - experiment feeds, positioning, historical activity etc - or is that found elsewhere?

There's this website ( http://isslive.com/displays/index.html ) with amazing amounts of live data hidden behind a horrible UI.

For example, right now I can see that control gyroscope #1 is spinning at 6,601 rpm, drawing 0.67 amps, and have a vibration of 0.007Gs, with bearing temperatures of 39.1C, and 35.8C.

I looked into snarfing the data at one point, and concluded that it was doable, if a little painful.

Another good real-time one is the DSN, the network of antennas that communicates with probes throughout the solar system:

https://eyes.nasa.gov/dsn/dsn.html

Looks like they use https://github.com/tripit/slate

Very cool. Anyone has ideas on how this data can be used, what kind of applications can be built with this?

Hi, I just build a small Android app using the rover-photo APIs: https://play.google.com/store/apps/details?id=com.siddharths...