ENH: Initial implementation of calculation of astronomical Julian Date.
- Added 'to_julian_date()' to Timestamp
- Added 'to_julian_date()' to DatetimeIndex
- Added tests for both methods.

Toying with the idea of using pandas for my astronomy and tidal analysis packages and I need the astronomical Julian Date.  So here is an implementation and tests.  I think I put these in the right place.  Really wanted to have the same function for the Timestamp and DatetimeIndex so that both would benefit from improvements, but couldn't figure out how to make that work.

Kindest regards,
Tim

can you hook up travis (see contributing in main pandas dir)
 As an aside, you could probably combine most of your tests into 2 tests (check out some of the other test cases in tseries/tests and core/tests to get an example) - just nice to follow the format of the rest of the test suite.
 @timcera how's this coming along? would be a nice addition....
 This issue (https://github.com/pydata/pandas/issues/4065) is why I haven't worked on this.  What is the use to me to implement a calendar that starts in 4714 BC (proleptic gregorian), if pandas can't represent the date?

I tried to wade through the pandas code to help out with https://github.com/pydata/pandas/issues/4065, but quickly got in way over my head.

Back to this PR, it seems that the only issues are that I need to hook up travis, and possibly change the tests?    Is there anything else?  It is possible that I could do these things soonish.  

My main concern though that I haven't got any feedback on is whether this is the right way to implement this functionality.  Should it be a part of the Timestamp and Datetimeindex OR should it be a seperate utility function?  Is there a pandas way?  What is the big picture in how this should be implemented?  Should pandas even care about calendars other than gregorian?  Would other calendars make sense?  Should the julian date be a completely separate object with a 'to_gregorian()' function?  Should I just keep this functionality in my code?  Should it be represented as a tuple (integer day, float fraction of day) which would allow representation of smaller intervals.  I don't have any tests for small intervals though I include nanosecond in the calculations - don't know whether it actually does anything.

Kindest regards,
Tim
 @timcera 

I think your implementation is just fine, and since they return `float` for `Timestamp` and an `ndarray` for `DatetimeIndex` I don't see a problem

The calendar issue is separate (and complicated), you might find [this](http://pandas.pydata.org/pandas-docs/dev/timeseries.html#custom-business-days-experimental) interesting (docs have a build problem, but you can get the idea)
 need to remove the merge branches

you can just
`git rebase -i < before the first commit >`
and delete commits other than 76979a2
 I have the rebase correct now, but trying to push to my repository with:

```
git push origin to_julian
```

Returns the following error:

To git@github.com:timcera/pandas.git
 ! [rejected]        to_julian -> to_julian (non-fast-forward)
error: failed to push some refs to 'git@github.com:timcera/pandas.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Any suggestions?
 use git push --force origin to_juilian
 @timcera circling back on these open PR's....still interested in this?

pls rebase....#4065 was fixed...so let's see
 Still interested.  

Rebased to the latest.  I think it looks right, but if there are any issues, would be glad to work at getting things in order.

Kindest regards,
Tim
 converting a DatetimeIndex returns a float array yes?
I think it's reasonable to return a Float64index

pls add a release note under new features for 0.14 and a mention in v0.14.0.txt
as well as a doc string

ideally always would like to see your tests in tseries/test_timeseries.py
u can keep them in classes like u have now. (maybe need an expanded name to fit in though
eh TestDatetimeIndexJulsnDate )
 Looking at this should probably include a Float64Index.to_gregorian().  Might actually be more useful than the 'Datetime.Index.to_julian()'.  Might need to be clear in the name though - perhaps Float64.Index.julian_date_to_gregorian()?
 Travis was failing, but because of a testing bug fixed in a2c99fd78e0e924555b1fc86dd628073132ebccf

I rebased to the latest upstream and pushed that changes up again.

Kindest regards,
Tim
 Forgot to add a docstring to Timestamp.to_julian()

I can squash these commits.  I don't know what the preferred view is.
 I think it makes sense to add to period / period index as well (esp since periods CAN represent dates that are out if bounds for time stamps )

but this will require a common mixin class for period index / DatetimeIndex (which I need to add anyhow)

so this looks ready to merge?
 I think it is ready.
 merged via https://github.com/pydata/pandas/commit/10ad9dd4922ca5ef0dd06d4135f315248b0d2c05

thanks!
