pyephem - 太阳的赤经计算是否考虑了时间方程
pyephem - does the right ascension calculation for the sun account for the Equation of Time
我正在寻找在特定日期时间时刻计算太阳下点的最高精度经纬度，如果需要的话，在其他一些图书馆的帮助下，使用 pyephem 是合理的。
相关上下文：
任何使用过 pyephem 的人都知道，对于某些计算，在计算 body 位置之前需要某些 setup 值，这些值包括日期时间（观察的时期）、位置观察者，当然还有正在调查的body。我在网上找到的通过使用 pyephem 的太阳下点的解决方案，将 utc 中的时间显示为 pyephem setup 所需的时间.
回想起我第一次接触天文学和天体导航时，utc 是 平日，与实际太阳日相比，由于地球轨道性质的几个因素，一年中实际太阳日的持续时间有所不同。由于实际太阳日的长度全年变化，对于某些类型的天文计算，这需要 时间方程 更精确地将实际太阳日测量值映射到平均和固定24 小时制，例如 utc。在足够精确的 'pendulum movement' 时钟机制出现之前，现在 crystal 控制时钟机制，回到日晷是准确计时器的时候，更复杂的日晷包括标记以应用这个重要的每年近似值 时间方程式，在它被观察并明确记录后不久。因此，与我的问题相关，因为 utc 是平日的变体，而不是真正的太阳日，但准确地归一化为 24 小时，现在有一个问题是 pyephem 如何或是否将时间方程纳入其太阳赤经解。目前，我想 EoT 需要准确度，因为我试图想象太阳在星星背景下的位置，从地球上看，当地球围绕太阳旋转时， 时间方程 提供了可用且有用且必不可少的历史观察变化。
然后总结我的问题：
如果不需要在 pyephem 中明确输入 EoT 值，因为它与计算最准确的太阳下点无关，请解释原因。如果它是相关的，正如我目前认为的那样，请告诉我 pyephem，在太阳（和其他天体）的赤经计算中，作为 body，实际上是否应用了 时间方程 视情况而定。它这样做 透明 吗？有没有办法为它输入一个明确的值，如果已知，一个 EoT 值可能比 pyephem 使用的值更准确或更新 透明?
构成问题的一些初步研究结果：
通过各种搜索引擎进行搜索后，我在主题论坛中发现了几个 post，它们给出了看起来非常简单的寻找太阳下点的答案。找到纬度似乎是解决方案中不太复杂的部分，只是计算赤纬。找到经度是我思考的问题所在，现在我想知道它是否也适用于赤纬，因为使用适当精确的 time 对于最精确的结果至关重要太阳下点的赤纬（纬度）和经度。当我参与天体导航时，我总是应用航海年鉴中的 EoT。
两个 links，特定于 pyephem，对太阳下点解决方案提出了相同的方法。首次提出问题时，Brandon Rhodes 使用 pyephem 对太阳赤经的计算迅速给出了单线公式。他特别是用更理论化的语气计算经度的代码，没有所有 pyephem 上下文细节。 Liam Kennedy 提供了一个更完整的 python 代码上下文，显示了那些额外的 pyephem 细节，这样就可以 'copy and paste' 整个代码块，（只需要添加 import ephem 和 import datetime），以及适当修改它，我也发现这是一个有用的评论。代码来自这些 links...
Computing sub-solar point
Confusion with using dec/ra to compute sub-lunar location
太阳下点：
布兰登的代码
lon = body.ra - greenwich.sidereral_time()
利亚姆的密码
sunLon = math.degrees(sun.ra - greenwich.sidereal_time() )
在这两个 post 中没有任何地方提到 时间方程，但 的变体均日 在这里用作输入值
greenwich.date = datetime.utcnow()
ut 作为 mean day 的变体是 EoT 不知道的，根据其构造定义作为 mean day，这通常要求使用 EoT 对其进行调整以获得某些天文用途。
为了进一步阐明这一要求，有许多导航和天文参考资料对它进行了相当详细的讨论。但我会坚持参考一些论坛 post，例如：
https://forum.cosmoquest.org/showthread.php?55871-Finding-the-subsolar-point
特别是 post by grant hutchison 2007-mar-20, 04:33 pm
You can use the NOAA Solar Position Calculator, but it's kind of convoluted.
注意：截至撰写本文时，NOAA 计算器 2019-12-19 确实有一个输入框，可以在其中输入 时间方程（以分钟为单位）。该页面有一个 link 更新的计算器。
https://www.esrl.noaa.gov/gmd/grad/solcalc/
更新的页面还计算并显示了时间方程，阐明了它的相关性。现在，继续引用格兰特的 post...
First, use the calculator to derive the Equation of Time and Solar Declination for the date and time you're interested in, at the location zero latitude and zero longitude, with no UTC offset.
The 2007 March equinox is at 21 March 00:08:30 UTC. Type that time and date into the calculator and, sure enough, you find the solar declination is zero: the sun is over the equator at that moment. For any other date and time, the solar declination will convert directly to the latitude of the subsolar point.
Now we need the longitude. First, work out the true solar time using the Equation of Time figure: it's -7.42 minutes in this case. That's the offset between the position of the mean sun and the real sun. Adding that figure to our UTC time tells us that the real sun is just 1.03 minutes past midnight (8.5-7.42) at the time of interest. Divide that figure by 60*24 (to get the fraction of a day) and multiply by 360 (to get degrees): that gives us 0.2575 degrees past midnight. So the sun will be on the noon meridian at 180-0.2575 degrees east = 179.7425 E. That's our longitude.
Combine the two, and the subsolar point is 0.0000N 179.7425E.
We can check that I haven't mixed my pluses and minuses by typing the derived coordinates of the subsolar point into the solar calculator (Lat 00:00:00, Lon -179:44:33), keeping the UTC offset at zero and the date and time at your time of interest, 21 March 00:08:30. That comes up with an Azimuth of zero and an Altitude of 89.98 degrees, confirming that we have the sun crossing the meridian within a couple of hundredths of a degree of directly overhead. Phew. It works, but it's a bit of a pain. Maybe someone can offer a calculator that will do more of the work for you.
大约一个半小时后，他的后续 post 约会...
Some notes to the above, FWIW:
The difference between Dynamical Time and UTC this year is 65 seconds, so working from the Dynamical Time of the solstice we get the UTC time (to the nearest second) to be 00:07:25 UTC, which fits with G O R T's nearest-minute value, above.
The reason G O R T and I come up with a different subsolar longitude for the same time (00:07:00 UTC) is because of that pesky -7.42 minutes in the equation of time: although that time is after midnight at Greenwich, the real sun is still 42 seconds short of crossing the midnight line. That shifts the calculated subsolar point from the eastern to the western hemisphere. 7.42 minutes is equivalent to 1.855 degrees, which is exactly the difference between my calculated longitude of 179:53:42W and G O R T's of 178:15:00E.
因此，我的问题是基于这项研究，并基于我过去在天体导航方面的经验。我想 时间方程 可能对问题很重要，它会被纳入 pyephem 的计算中，因为 平均日 被输入到 pyephem 的 API。在这些片段解决方案 postings 中看不到任何地方 EoT 将在 pyephem API 中指定，我的假设是它将在内部透明地实施？我对这个假设不满意，所以我 post 编辑了这个问题。澄清将有利于用户的信心，尤其是像我这样的新手。
2019 年 12 月 20 日更新：
我怀疑答案是肯定的，pyephem 占 EoT，但它不这么称呼它？ ephem，libastro 考虑 一些其他影响或关系 的方式可能回答了我的问题。我正在评论：
https://rhodesmill.org/pyephem/radec
需要非常缓慢地阅读它，一边画一些图，一边等待一本天文学书，这样我就可以赶上关于这个问题的非常错位教育。我在想，也许术语 时间方程 仅在将太阳日与平日度量标准相协调的狭义背景下有意义，正如地球上所经历的那样，而 pyephem 在更广泛的范围内解决上下文并使用更广泛适用的术语，其中我需要 re-educated，其中包括诸如 时间方程 这样的结果效果？还是我只是在展示我的无知？在我能够更胜任地写出自己的答案之前，请提供任何可以指导我的学习的有用评论或答案。
我认为您的问题更简单地说是：作为 PyEphem 基础的 libastro 库是否假设地球的轨道是一个圆，地球沿着该圆以均匀的速度运行？因为如果它假设地球的圆形轨道和均匀速率，那么就需要出现一个校正——时间方程——因为地球实际上沿其轨道改变了它的速度。
我建议你可以通过实验自己回答这个问题。如果 PyEphem 假设地球做匀速圆周运动，那么太阳每天移动的度数将是相同的。尝试循环一连串的日子。在每天的同一时间，询问太阳的赤经和赤纬，然后使用 separation() 检查这些点之间经过的角度。
如果太阳行进的角度每天都相同，那么 PyEphem 对太阳运动的建模非常糟糕，您需要应用时间方程校正来获得它的真实位置。
但是，如果每天的角度在变化——7 月小，1 月大——那么 PyEphem 必须更准确地模拟地球运动。如果你深挖源码，你会发现它的模型叫做预测地球和太阳位置的VSOP87模型。您自己的实验应该显示模型在一年中太阳在天空中移动时的行为。
我正在寻找在特定日期时间时刻计算太阳下点的最高精度经纬度，如果需要的话，在其他一些图书馆的帮助下，使用 pyephem 是合理的。
相关上下文： 任何使用过 pyephem 的人都知道，对于某些计算，在计算 body 位置之前需要某些 setup 值，这些值包括日期时间（观察的时期）、位置观察者，当然还有正在调查的body。我在网上找到的通过使用 pyephem 的太阳下点的解决方案，将 utc 中的时间显示为 pyephem setup 所需的时间.
回想起我第一次接触天文学和天体导航时，utc 是 平日，与实际太阳日相比，由于地球轨道性质的几个因素，一年中实际太阳日的持续时间有所不同。由于实际太阳日的长度全年变化，对于某些类型的天文计算，这需要 时间方程 更精确地将实际太阳日测量值映射到平均和固定24 小时制，例如 utc。在足够精确的 'pendulum movement' 时钟机制出现之前，现在 crystal 控制时钟机制，回到日晷是准确计时器的时候，更复杂的日晷包括标记以应用这个重要的每年近似值 时间方程式，在它被观察并明确记录后不久。因此，与我的问题相关，因为 utc 是平日的变体，而不是真正的太阳日，但准确地归一化为 24 小时，现在有一个问题是 pyephem 如何或是否将时间方程纳入其太阳赤经解。目前，我想 EoT 需要准确度，因为我试图想象太阳在星星背景下的位置，从地球上看，当地球围绕太阳旋转时， 时间方程 提供了可用且有用且必不可少的历史观察变化。
然后总结我的问题：
如果不需要在 pyephem 中明确输入 EoT 值，因为它与计算最准确的太阳下点无关，请解释原因。如果它是相关的，正如我目前认为的那样，请告诉我 pyephem，在太阳（和其他天体）的赤经计算中，作为 body，实际上是否应用了 时间方程 视情况而定。它这样做 透明 吗？有没有办法为它输入一个明确的值，如果已知，一个 EoT 值可能比 pyephem 使用的值更准确或更新 透明?
构成问题的一些初步研究结果： 通过各种搜索引擎进行搜索后，我在主题论坛中发现了几个 post，它们给出了看起来非常简单的寻找太阳下点的答案。找到纬度似乎是解决方案中不太复杂的部分，只是计算赤纬。找到经度是我思考的问题所在，现在我想知道它是否也适用于赤纬，因为使用适当精确的 time 对于最精确的结果至关重要太阳下点的赤纬（纬度）和经度。当我参与天体导航时，我总是应用航海年鉴中的 EoT。
两个 links，特定于 pyephem，对太阳下点解决方案提出了相同的方法。首次提出问题时，Brandon Rhodes 使用 pyephem 对太阳赤经的计算迅速给出了单线公式。他特别是用更理论化的语气计算经度的代码，没有所有 pyephem 上下文细节。 Liam Kennedy 提供了一个更完整的 python 代码上下文，显示了那些额外的 pyephem 细节，这样就可以 'copy and paste' 整个代码块，（只需要添加 import ephem 和 import datetime），以及适当修改它，我也发现这是一个有用的评论。代码来自这些 links...
Computing sub-solar point
Confusion with using dec/ra to compute sub-lunar location
太阳下点：
布兰登的代码
lon = body.ra - greenwich.sidereral_time()
利亚姆的密码
sunLon = math.degrees(sun.ra - greenwich.sidereal_time() )
在这两个 post 中没有任何地方提到 时间方程，但 的变体均日 在这里用作输入值
greenwich.date = datetime.utcnow()
ut 作为 mean day 的变体是 EoT 不知道的，根据其构造定义作为 mean day，这通常要求使用 EoT 对其进行调整以获得某些天文用途。
为了进一步阐明这一要求，有许多导航和天文参考资料对它进行了相当详细的讨论。但我会坚持参考一些论坛 post，例如：
https://forum.cosmoquest.org/showthread.php?55871-Finding-the-subsolar-point
特别是 post by grant hutchison 2007-mar-20, 04:33 pm
You can use the NOAA Solar Position Calculator, but it's kind of convoluted.
注意：截至撰写本文时，NOAA 计算器 2019-12-19 确实有一个输入框，可以在其中输入 时间方程（以分钟为单位）。该页面有一个 link 更新的计算器。
https://www.esrl.noaa.gov/gmd/grad/solcalc/
更新的页面还计算并显示了时间方程，阐明了它的相关性。现在，继续引用格兰特的 post...
First, use the calculator to derive the Equation of Time and Solar Declination for the date and time you're interested in, at the location zero latitude and zero longitude, with no UTC offset.
The 2007 March equinox is at 21 March 00:08:30 UTC. Type that time and date into the calculator and, sure enough, you find the solar declination is zero: the sun is over the equator at that moment. For any other date and time, the solar declination will convert directly to the latitude of the subsolar point.
Now we need the longitude. First, work out the true solar time using the Equation of Time figure: it's -7.42 minutes in this case. That's the offset between the position of the mean sun and the real sun. Adding that figure to our UTC time tells us that the real sun is just 1.03 minutes past midnight (8.5-7.42) at the time of interest. Divide that figure by 60*24 (to get the fraction of a day) and multiply by 360 (to get degrees): that gives us 0.2575 degrees past midnight. So the sun will be on the noon meridian at 180-0.2575 degrees east = 179.7425 E. That's our longitude.
Combine the two, and the subsolar point is 0.0000N 179.7425E.
We can check that I haven't mixed my pluses and minuses by typing the derived coordinates of the subsolar point into the solar calculator (Lat 00:00:00, Lon -179:44:33), keeping the UTC offset at zero and the date and time at your time of interest, 21 March 00:08:30. That comes up with an Azimuth of zero and an Altitude of 89.98 degrees, confirming that we have the sun crossing the meridian within a couple of hundredths of a degree of directly overhead. Phew. It works, but it's a bit of a pain. Maybe someone can offer a calculator that will do more of the work for you.
大约一个半小时后，他的后续 post 约会...
Some notes to the above, FWIW:
The difference between Dynamical Time and UTC this year is 65 seconds, so working from the Dynamical Time of the solstice we get the UTC time (to the nearest second) to be 00:07:25 UTC, which fits with G O R T's nearest-minute value, above.
The reason G O R T and I come up with a different subsolar longitude for the same time (00:07:00 UTC) is because of that pesky -7.42 minutes in the equation of time: although that time is after midnight at Greenwich, the real sun is still 42 seconds short of crossing the midnight line. That shifts the calculated subsolar point from the eastern to the western hemisphere. 7.42 minutes is equivalent to 1.855 degrees, which is exactly the difference between my calculated longitude of 179:53:42W and G O R T's of 178:15:00E.
因此，我的问题是基于这项研究，并基于我过去在天体导航方面的经验。我想 时间方程 可能对问题很重要，它会被纳入 pyephem 的计算中，因为 平均日 被输入到 pyephem 的 API。在这些片段解决方案 postings 中看不到任何地方 EoT 将在 pyephem API 中指定，我的假设是它将在内部透明地实施？我对这个假设不满意，所以我 post 编辑了这个问题。澄清将有利于用户的信心，尤其是像我这样的新手。
2019 年 12 月 20 日更新：
我怀疑答案是肯定的，pyephem 占 EoT，但它不这么称呼它？ ephem，libastro 考虑 一些其他影响或关系 的方式可能回答了我的问题。我正在评论：
https://rhodesmill.org/pyephem/radec
需要非常缓慢地阅读它，一边画一些图，一边等待一本天文学书，这样我就可以赶上关于这个问题的非常错位教育。我在想，也许术语 时间方程 仅在将太阳日与平日度量标准相协调的狭义背景下有意义，正如地球上所经历的那样，而 pyephem 在更广泛的范围内解决上下文并使用更广泛适用的术语，其中我需要 re-educated，其中包括诸如 时间方程 这样的结果效果？还是我只是在展示我的无知？在我能够更胜任地写出自己的答案之前，请提供任何可以指导我的学习的有用评论或答案。
我认为您的问题更简单地说是：作为 PyEphem 基础的 libastro 库是否假设地球的轨道是一个圆，地球沿着该圆以均匀的速度运行？因为如果它假设地球的圆形轨道和均匀速率，那么就需要出现一个校正——时间方程——因为地球实际上沿其轨道改变了它的速度。
我建议你可以通过实验自己回答这个问题。如果 PyEphem 假设地球做匀速圆周运动，那么太阳每天移动的度数将是相同的。尝试循环一连串的日子。在每天的同一时间，询问太阳的赤经和赤纬，然后使用 separation() 检查这些点之间经过的角度。
如果太阳行进的角度每天都相同，那么 PyEphem 对太阳运动的建模非常糟糕，您需要应用时间方程校正来获得它的真实位置。
但是，如果每天的角度在变化——7 月小，1 月大——那么 PyEphem 必须更准确地模拟地球运动。如果你深挖源码，你会发现它的模型叫做预测地球和太阳位置的VSOP87模型。您自己的实验应该显示模型在一年中太阳在天空中移动时的行为。