{"issue":{"pull_request":{"diff_url":"https://github.com/astropy/astropy/pull/57.diff","html_url":"https://github.com/astropy/astropy/pull/57","patch_url":"https://github.com/astropy/astropy/pull/57.patch"},"state":"open","user":{"avatar_url":"https://secure.gravatar.com/avatar/1d04093195c84a081b7348dcc1b43dd6?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"1d04093195c84a081b7348dcc1b43dd6","url":"https://api.github.com/users/wkerzendorf","login":"wkerzendorf","id":506116},"milestone":null,"assignee":null,"updated_at":"2011-11-11T04:32:58Z","labels":[],"comments":37,"closed_at":null,"url":"https://api.github.com/repos/astropy/astropy/issues/57","body":"Hello Guys,\r\n\r\nWith all the suggestions onboard I have started to do the astrotime implementation.\r\nSo here's what works:\r\n\r\nfrom astropy import astrotime\r\nimport datetime\r\nmytime = astrotime.AstroTime.from_date_gregorian(datetime.datetime(2005, 25, 8, 12, 0, 0))\r\nmytime.to_jd()\r\nsome number comes out.\r\n\r\nI have looked at SOFA and other Astronomical Almanac and used their algorithm - to make sure they are right.\r\nI have also added tests to the astrotime directory and they check out with pytest.\r\n\r\nThere's also somethings awry with the documentation, but that's because I'm new to sphinx.\r\n\r\nAh very important: I've thought about what Tom A. and I think Prasanth mentioned: Speed. Yes I completely agree that our current implementation of an object is not optimized for speed and thought about other implementations. I think a solution for this problem is to say: Please use np.float64 MJD as a standard if you need the speed and use this function to convert when speed and memory footprint is not crucial!. I think we should put this in the documentation.\r\n\r\nWhat do you guys think?\r\n\r\nCheers,\r\n    Wolfgang\r\n\r\n","html_url":"https://github.com/astropy/astropy/issues/57","title":"Astrotime","number":57,"id":2171177,"created_at":"2011-11-08T05:25:53Z"},"action":"created","comment":{"user":{"avatar_url":"https://secure.gravatar.com/avatar/b2a66b4a75397bcd42fdd7bb399ee553?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"b2a66b4a75397bcd42fdd7bb399ee553","url":"https://api.github.com/users/eteq","login":"eteq","id":346587},"updated_at":"2011-11-11T04:32:58Z","url":"https://api.github.com/repos/astropy/astropy/issues/comments/2704885","body":" Actually, when I think about it, perhaps what we really want is an abstract base class like ``TimeBase`` that implements whatever can easily be expressed in standard operator notation, and provides abstract methods/properties for things like jd, mjd, and datetime objects.  Then I think we can get by with two subclasses: one that uses longs and has arbitrarily good precision, and one that's more like this pull request/the array classes I wrote.  \r\n\r\nPerhaps we can even get away with something even simpler like a single floating-point JD representation - that would be much easier to implement and is still fine for anything around the current era to microsecond precision. (see also my comments in the #59 pull request about single float vs int/float combo)","id":2704885,"created_at":"2011-11-11T04:32:58Z"}}