Python 太阳凌日时间的差异

执行此代码片段：

import ephem
oma=ephem.Observer()
oma.lat='50.7975189'
oma.lon='4.3579155'
oma.elevation=114.43
oma.epoch=ephem.now()
sun=ephem.Sun(oma)
print "object transit time: ",sun.transit_time
print "observer next transit time: ", oma.next_transit(sun)

这将提供以下输出：

object transit time:  2012/9/5 11:41:03
observer next transit time:  2012/9/5 11:41:06

object transit time:  2012/9/5 15:05:32
observer next transit time:  2012/9/5 15:05:32

因此，太阳物体的时间与为太阳观测者计算的时间相差3秒。这两者中哪一个最可靠？如果我们将这些值与本地计算值进行比较，则观察者下一次通过时间最接近

如果我们对火星做同样的计算：

import ephem
oma=ephem.Observer()
oma.lat='50.7975189'
oma.lon='4.3579155'
oma.elevation=114.43
oma.epoch=ephem.now()
mars=ephem.Mars(oma)
print "object transit time: ",mars.transit_time
print "observer next transit time: ", oma.next_transit(mars)

这将提供以下输出：

object transit time:  2012/9/5 11:41:03
observer next transit time:  2012/9/5 11:41:06

object transit time:  2012/9/5 15:05:32
observer next transit time:  2012/9/5 15:05:32

所以没有区别

致以最良好的祝愿

---

大理石

这是由于观察者的过境时间不合适

我改进并更改了您的代码：

from ephem import Observer, Sun, now
oma=Observer()
oma.lat='50.7975189'
oma.lon='40.3579155'
oma.elevation=114.43
oma.epoch=now()
sun=Sun(oma)
print "object transit time: ",sun.transit_time
print "observer next transit time: ", oma.next_transit(sun)

这就产生了：

object transit time:  2012/9/6 09:16:48
observer next transit time:  2012/9/7 09:16:27

现在，为什么有一天的差异（或-11秒）将lon从4更改为40？

---

以弗所表示的lon和lat是什么单位？我想这不是问题的一部分。

要确定哪个函数最准确，只需将它们给你的两次输入观测者的

compute（）

函数，然后查看当方位角正好为180°时，哪个着陆点最接近实际的经纬度：

import ephem
oma = ephem.Observer()
oma.lat, oma.lon = '50.7975189', '4.3579155'
oma.elevation = 114.43
sun = ephem.Sun()
for t in ('2012/9/5 11:41:03',
          '2012/9/5 11:41:06'):
    oma.date = t
    sun.compute(oma)
    print 'azimuth at', t, 'was', sun.az

此脚本的输出显示，较新的

next_transit（）

函数的

11:41:06

时间给出了更准确的结果：

azimuth at 2012/9/5 11:41:03 was 179:58:45.4
azimuth at 2012/9/5 11:41:06 was 179:59:49.5

旧的

.transit\u time

属性的精确度较低，这就是为什么当前的Pypehem文档建议对其适用的所有transit计算始终使用

next\u transit（）

。（这意味着除了地球卫星以外的一切，对于地球卫星，

.transit\u time

无论如何都会切换到不同的算法。）

事实上，当前的文档甚至没有提到请求非地球卫星的

.next_transit

甚至是可能的，并且该属性仅用于古代向后兼容性

这两个函数的工作方式是相同的：猜测一个时间，检查当时的方位角，然后反复完善猜测，直到他们喜欢答案。最近的

next\u transit（）

函数可以更好地实现这一点，因此您应该使用它

这两个函数对火星给出相同答案的原因只是巧合——如果你在9月5日以外的其他日期对火星运行函数，你会看到不同的答案。这完全取决于函数进行一系列猜测的顺序，以及最后的猜测是靠得很近还是相隔很远。而且，我敢打赌，即使是在9月5日，他们的答案也并不完全匹配——他们只是匹配到了第二个答案，而第二个答案就是他们展示的全部！如果您要通过打印每个答案的

repr（float（…）

来显示这两个答案的全精度朱利安日期，那么毫无疑问，您会发现小数点下方的分歧远远低于1秒的分辨率

这涵盖了你所有的担忧吗