p.s. I'm not quite sure what the automatic failure is about. Will investigate later, but for now maybe it is just as well that travis doesn't burn cycles on this -- mostly posting this for a first look to see whether there is agreement on the direction.

@jwoillez - to get Time to work properly with the new erfa, including for scalars, I had to make a small change to how scalars are handled for numpy <1.8 (mhvk@ed34808). I use reshape instead of getting an item, which ensures that the output remains an ndarray (as happens for numpy >1.8). Could you have a look? If you agree this is sensible, I can add some erfa test cases here (or split out into a new PR).

@taldcroft - I now have all tests passing with a much simplified way of handling scalars (since erfa can now handle them), and this also allows arbitrary dimensions in Time. I will write some test cases for the latter, but in the meantime, it would be useful if you could have a look.

One particular change that I made is to treat input of Time objects just like any other, letting it become an array of with object dtype.

@eteq - just to be clear, while my change to erfa.py.templ is small, the propagation to erfa.py means there are many changes there. So if I understand correctly, from a don't-make-git-history-overweight perspective, it might be advantageous to wait for #3159 before merging this?

@mhvk - this looks awesome, thanks! So the main thing is to add tests for multi-dim as you said. I think there also need to be a bit more depth in testing the scalar case, especially for Time and DateTime inputs (and other cases where the use of nditer was introduced).

Yes, I'll try to add some more scalar tests as well; for these, jd1 and jd2 are now stored as array scalar, and that already managed a few times to unintendedly percolate through.

OK, the multidimensional Time seems fairly complete now in tests as well. It may be good to wait for the erfa implementation to settle, though.

OK, after rebasing with #3166 in, this no longer depends on how erfa is done and should thus be ready for final review.

Finished code review and it looks great (once Travis passes). Just need to add some mention of the multi-dim capability and broadcasting of inputs in the docs. The "Scalar or Array" section would be a good place. And of course CHANGES.rst.

Thanks! I added documentation and hopefully resolved the numpy <= 1.8 bug (the earlier solution of which disappeared with my rebase...).

I realised we could take this further and define reshape, ravel, transpose, etc., but think that is better left for a later PR, as it needs some care with broadcasting the other array properties. (edit: issue #3224)

@taldcroft - do you want to have a quick look at the last commit with the documentation? I think this is ready to go in.

@taldcroft - just in case: don't merge this yet -- waiting for #3173 to go in first...

@mhvk - #3173 is in so, rebase when ready (or #3173 - whichever order is easier on you)

@taldcroft - ok, now rebased again, and it should really be all OK. Maybe just have a quick look over the documentation.

Docs look good, but it seems you need to rebase again.

👍 feel free to merge!

Assuming this is a new feature since Astropy 0.4; i.e. new functionality that did not previously exist, this should be labeled Affects-release, not Affects-dev. Affects-dev means "this pertains to an issue that will only ever be seen by people developing Astropy, not users of released versions".

OK, here I was thinking affects-release means it affects an already existing release.

In a way it does--it provides an enhancement over existing releases.

These categorizations just help me figure out what needs to go where, and also helps me a lot when preparing a release to make sure everything's in its right place.