<p>I worked out the GMST using the method described in <a href="http://aa.usno.navy.mil/faq/docs/GAST.php" rel="nofollow noreferrer">http://aa.usno.navy.mil/faq/docs/GAST.php</a>. This should be an authoritative source, and claims 0.1 second accuracy.</p>

<p>In pseudo-code:</p>

<pre><code>midnight = floor(2458484.833333) + 0.5            // J0 = 2458484.5
days_since_midnight = 2458484.833333 - 2458484.5  // = 0.333333
hours_since_midnight = 0.333333 * 24              // H = 8.0
days_since_epoch = 2458484.833333 - 2451545.0     // D = 6939.833333
centuries_since_epoch = days_since_epoch / 36525  // T = 0.190002
whole_days_since_epoch = 2458484.5 - 2451545.0    // D0 = 6939.5

GMST = 6.697374558 
     + 0.06570982441908 * whole_days_since_epoch 
     + 1.00273790935 * hours_since_midnight
     + 0.000026 * centuries_since_epoch**2        //=470.712605328

GMST_hours = 470 % 24 // = 14
GMST_minutes =  floor(0.712605328 * 60) //=42(.7563197)
GMST_seconds =  0.7563197*60 // =45.38
</code></pre>

<p>This calculation agrees with the online calculator. The method here (or as described at the link) should be easy to implement.</p>

CC BY-SA 4.0
2018-06-12T21:47:15.663Z
James - A minor error your pseudo-code: In your final calculation for GMST, you show the variable hours_since_epoch. This should be hours_since_midnight.
Robert Smith
CC BY-SA 4.0
2018-06-13T07:47:23.167Z
@RobertSmith  Cured.
James K
CC BY-SA 4.0
2017-05-12T17:25:38.623Z
2018-11-05T20:55:25.280Z
2018-11-05T20:55:25.280Z
James K
<blockquote>
  <p>To do so, I'm following what's described in <a href="http://earth-info.nga.mil/GandG/publications/tr8350.2/tr8350.2-a/Appendix.pdf" rel="noreferrer">this document</a> and implementing C++ code.</p>
</blockquote>

<p>That is a very old document you are using. It's using the 1982 IAU precession model. There have been multiple updates since then. The latest set of changes are working toward eliminating the concept of Greenwich Sidereal Time. (In software terms, GMST and GAST are deprecated concepts. While still currently supported, support will be dropped in some future release of the Earth rotation model.)</p>

<hr>

<p>Other than using an outdated version of a deprecated concept, what did you do wrong? The expression you are using to compute GMST is at the top of page A-26:
$$\Lambda = H_0 + \Delta H + \omega^{\ast}\,(t-\Delta t)$$
The $\Delta H$ term takes one from GMST to GAST. Dropping that term, the expression for GMST is
$$H = H_0 + \omega^{\ast}\,(t-\Delta t)\tag1$$
where
$$\begin{align}
H_0 = &amp;\,24110.54841 + 8640184.812866 T_u + 0.093104 {T_u}^2 - 6.2\times10^{-6} {T_u}^3\tag 2 \\
&amp;\,\text{is the Greenwich sidereal time at midnight, in seconds of time} \\
\omega^{\ast} = &amp;\,7.2921158553\times10^{-5} + 4.3\times10^{-15} T_u\tag3 \\
&amp;\,\text{is the Earth's sidereal rotation rate, in radians}/\text{second} \\
t\phantom{\Delta}\quad&amp;\text{is UTC time of day, in seconds, and} \\
\Delta t\quad&amp;\text{is the difference between UT1 and UTC.}
\end{align}$$</p>

<p>Note that there's a units mismatch in equation (1). Equation (2) yields a result in units of sidereal seconds while equation (3), when multiplied by time of day, yields a result in units of radians. The latter needs to be converted to sidereal seconds. To do this, simply multiple both terms in equation (3) by $\frac{86400}{2\pi}$:</p>

<p>$$\begin{align}
\omega^{\ast} = &amp;\,1.00273790935 + 5.9\times10^{-11} T_u\tag4 \\
&amp;\,\text{is the Earth's sidereal rotation rate, in sidereal seconds}/\text{UT second}
\end{align}$$</p>

<p>Applying this to 2019 Jan 01 08:00:00 UTC yields the following:</p>

<ul>
<li>The Julian date at midnight UTC 2019 Jan 01 is $2458484.5$, or $2451545+6939.5$. See footnote 1 for an explanation of this convention.</li>
<li>Dividing the residual 6939.5 by 36525 yields $T_u$: $T_u = 6939.5 / 36525 = 0.1899931553730322$.</li>
<li>Applying equation (2) yields the Greenwich Mean Sidereal Time at midnight: $H_0 = 1665686.527373333$ sidereal seconds.</li>
<li>Applying equation (4) and multiplying by $t=8*3600$ seconds yields another 28878.85178960284 sidereal seconds to the above. What about $\Delta t$, aka dUT1? I've ignored it (i.e., treated it as if it was zero.) See footnote 2.</li>
<li>1665686.527373333 + 28878.85178960284 = 52965.37916293584 (modulo 86400). This is the mean sidereal time, in seconds. Converting to hours, minutes and seconds results in 14:42:45.4. The 0.4 seconds is bogus because I ignored dUT1.</li>
</ul>

<hr>

<p>Footnotes:</p>

<ol>
<li><p>There's a problem with using Julian dates to express time when high precision is of concern. The problem is that adding 2.45 million and change to the time since noon on 1 Jan 2000 results in potential truncation problems. The next representable Julian date after midnight 1 Jan 2000 is 40 microseconds after midnight. I myself try to stay a couple of orders of magnitude away from the quantization level, which means problems for dates at the millisecond level.</p>

<p>Almost every scientific package that supports Julian dates either uses a pair of double precision numbers or uses some sort of modified Julian date, such as time since 12 Noon 16 Nov 1858 (omits the leading 2.4 million in Julian date), time since 12 noon 23 May 1968 (omits the leading 2.44 million), or time since J2000.</p></li>
<li><p>The term $\Delta t$ in equations (2) and (4) is better known as dUT1. This is the difference between UT1 (time using the mean rotating Earth as a clock) and UTC (time that runs at the same rate as an atomic clock, but with leap seconds occasionally inserted to keep UT1 and UTC in sync). Those leap seconds keep $|\text{UT1}-\text{UTC}| &lt; 0.9\,\text{seconds}$. Simply ignore the $\Delta t$ term if that's the case -- but remember that fractions of a second are meaningless.</p></li>
</ol>

CC BY-SA 3.0
2017-05-15T09:14:13.813Z
Thanks for your comprehensive answer, it did really help! I finally found the problem that was causing wrong coordinate conversion and, unfortunately for this forum, it has fallen in the area of wrong unit conversion and signed operations. I plan to upload my C++ code in order to contribute a little but I'd love to know what would be the current/appropriate model to use if not this outdated one. Could you kindly provide a reference?
Carles Araguz
CC BY-SA 3.0
2017-05-15T09:36:56.593Z
@CarlesAraguz -- Two references! One is the International Earth Rotation and Reference Systems Service (IERS) Conventions, described in [IERS Technical Note 36](https://www.iers.org/IERS/EN/Publications/TechnicalNotes/tn36.html?nn=94912). Pay particular attention to chapters 4 and 5. The other is the Standards of Fundamental Astronomy (SOFA) open source software maintained by the International Astronomical Union (IAU) at http://www.iausofa.org . If you poke, you'll see lots of functions in C and Fortran, plus some "cookbooks".The cookbook of interest is http://www.iausofa.org/sofa_pn_c.pdf .
David Hammen
CC BY-SA 4.0
2019-03-06T10:56:51.667Z
just a question @David Hammen In equation(3), to convert from radians to sidereal seconds, the expression shouldn't been multiplied by 86164/2π, where 86164 is the number of seconds in one sidereal day? (t−Δt) is in sidereal seconds (even if Δt is ignored), since t(UTC) and Δt(UTC-UT1) And so the result shouldn't be modulo 86164? Sorry but I could not reply with a comment
binghy
CC BY-SA 4.0
2019-03-07T08:43:28.913Z
@binghy - Multiplying by $\frac{86164}{2\pi}$ would be incorrect. $(t-\Delta t)$ yields UT1 seconds, not sidereal seconds. (If you already knew the time in sidereal seconds it would be game over; the whole point of this exercise is to convert UTC time to sidereal time.) Multiplying a value in units of $\frac{\text{radians}}{\text{UT second}}$  by $\frac{86400\,\text{UT seconds}/\text{solar day}}{2\pi\,\text{radians}/\text{sidereal revolution}}$ converts that value to units of $\frac{\text{sidereal revolutions}}{\text{solar day}}$. This is equivalent to units of sidereal seconds per UT second.
David Hammen
CC BY-SA 3.0
2017-05-13T15:58:21.740Z
2017-05-13T15:58:21.740Z
David Hammen
<p>I'm writing a program that converts position in the ECI (CIS, EPOCH JD2000.0) coordinate system to WGS 84 (CTS, ECEF) coordinates. To do so, I'm following what's described in <a href="http://earth-info.nga.mil/GandG/publications/tr8350.2/tr8350.2-a/Appendix.pdf" rel="nofollow noreferrer">this document</a> and implementing C++ code.</p>
<p>My knowledge of astrophysics is very limited, so I find it hard to understand some terms. Especially, I can't seem to understand properly how the Greenwich Mean Sideral Time is computed, and why I always get different values.</p>
<p>For instance (assuming time is <em><code>2019-01-01 08:00:00</code></em> and Julian Date is <code>2458484.833333</code>):</p>
<ul>
<li>If I use this on-line <a href="http://dc.zah.uni-heidelberg.de/apfs/times/q/form" rel="nofollow noreferrer">GMST calculator</a>, I find that GMST is <em><code>14:42:45.3766</code></em>.</li>
<li>If I use the expression used in <a href="http://es.mathworks.com/matlabcentral/fileexchange/28233-convert-eci-to-ecef-coordinates?focused=5234019&amp;tab=function" rel="nofollow noreferrer">this MATLAB script</a> (showing the value in time, not degrees) I also get <em><code>14:42:45.350</code></em>.</li>
<li>However, if I calculate it myself with the expression given in the above appendix, I get <em><code>06:42:45.379163</code></em> (with a clear offset of</li>
</ul>
<p>According to the equations in page A-26, GMST depends upon the number of Julian centuries (Tu). H0 expression is exactly the same than that of <a href="https://celestrak.org/columns/v02n01/" rel="nofollow noreferrer">CelesTrak</a> for θ(0h). However, I can't really understand what the <strong>du</strong> truly stands for, or more specifically, why the document shows <code>du → ±0.5, 1.5, 2.5...</code>. Moreover, to find Λ (which is stated to be in <em>seconds of time</em>) the expressions use values in radians and seconds of time indistinctly.</p>
<p>Could somebody shed light into this?</p>

<coordinate><time><orbital-mechanics>
How to find Greenwich Mean Sideral Time?
Carles Araguz
# How to find Greenwich Mean Sideral Time?

(Asked by: username_0 on 2017-05-12)

I'm writing a program that converts position in the ECI (CIS, EPOCH JD2000.0) coordinate system to WGS 84 (CTS, ECEF) coordinates. To do so, I'm following what's described in [this document](http://earth-info.nga.mil/GandG/publications/tr8350.2/tr8350.2-a/Appendix.pdf) and implementing C++ code.

My knowledge of astrophysics is very limited, so I find it hard to understand some terms. Especially, I can't seem to understand properly how the Greenwich Mean Sideral Time is computed, and why I always get different values.

For instance (assuming time is *`2019-01-01 08:00:00`* and Julian Date is `2458484.833333`):

* If I use this on-line [GMST calculator](http://dc.zah.uni-heidelberg.de/apfs/times/q/form), I find that GMST is *`14:42:45.3766`*.
* If I use the expression used in [this MATLAB script](http://es.mathworks.com/matlabcentral/fileexchange/28233-convert-eci-to-ecef-coordinates?focused=5234019&tab=function) (showing the value in time, not degrees) I also get *`14:42:45.350`*.
* However, if I calculate it myself with the expression given in the above appendix, I get *`06:42:45.379163`* (with a clear offset of

According to the equations in page A-26, GMST depends upon the number of Julian centuries (Tu). H0 expression is exactly the same than that of [CelesTrak](https://celestrak.org/columns/v02n01/) for θ(0h). However, I can't really understand what the **du** truly stands for, or more specifically, why the document shows `du → ±0.5, 1.5, 2.5...`. Moreover, to find Λ (which is stated to be in *seconds of time*) the expressions use values in radians and seconds of time indistinctly.

Could somebody shed light into this?

**Tags:** coordinate, time, orbital-mechanics

---

## 2 answers

### Answer by username_3 on 2017-05-13. Score: 8 | Accepted answer

> To do so, I'm following what's described in [this document](http://earth-info.nga.mil/GandG/publications/tr8350.2/tr8350.2-a/Appendix.pdf) and implementing C++ code.

That is a very old document you are using. It's using the 1982 IAU precession model. There have been multiple updates since then. The latest set of changes are working toward eliminating the concept of Greenwich Sidereal Time. (In software terms, GMST and GAST are deprecated concepts. While still currently supported, support will be dropped in some future release of the Earth rotation model.)

---

Other than using an outdated version of a deprecated concept, what did you do wrong? The expression you are using to compute GMST is at the top of page A-26:
$$\Lambda = H\_0 + \Delta H + \omega^{\ast}\,(t-\Delta t)$$
The $\Delta H$ term takes one from GMST to GAST. Dropping that term, the expression for GMST is
$$H = H\_0 + \omega^{\ast}\,(t-\Delta t)\tag1$$
where
$$\begin{align}
H\_0 = &\,24110.54841 + 8640184.812866 T\_u + 0.093104 {T\_u}^2 - 6.2\times10^{-6} {T\_u}^3\tag 2 \\
&\,\text{is the Greenwich sidereal time at midnight, in seconds of time} \\
\omega^{\ast} = &\,7.2921158553\times10^{-5} + 4.3\times10^{-15} T\_u\tag3 \\
&\,\text{is the Earth's sidereal rotation rate, in radians}/\text{second} \\
t\phantom{\Delta}\quad&\text{is UTC time of day, in seconds, and} \\
\Delta t\quad&\text{is the difference between UT1 and UTC.}
\end{align}$$

Note that there's a units mismatch in equation (1). Equation (2) yields a result in units of sidereal seconds while equation (3), when multiplied by time of day, yields a result in units of radians. The latter needs to be converted to sidereal seconds. To do this, simply multiple both terms in equation (3) by $\frac{86400}{2\pi}$:

$$\begin{align}
\omega^{\ast} = &\,1.00273790935 + 5.9\times10^{-11} T\_u\tag4 \\
&\,\text{is the Earth's sidereal rotation rate, in sidereal seconds}/\text{UT second}
\end{align}$$

Applying this to 2019 Jan 01 08:00:00 UTC yields the following:

* The Julian date at midnight UTC 2019 Jan 01 is $2458484.5$, or $2451545+6939.5$. See footnote 1 for an explanation of this convention.
* Dividing the residual 6939.5 by 36525 yields $T\_u$: $T\_u = 6939.5 / 36525 = 0.1899931553730322$.
* Applying equation (2) yields the Greenwich Mean Sidereal Time at midnight: $H\_0 = 1665686.527373333$ sidereal seconds.
* Applying equation (4) and multiplying by $t=8\*3600$ seconds yields another 28878.85178960284 sidereal seconds to the above. What about $\Delta t$, aka dUT1? I've ignored it (i.e., treated it as if it was zero.) See footnote 2.
* 1665686.527373333 + 28878.85178960284 = 52965.37916293584 (modulo 86400). This is the mean sidereal time, in seconds. Converting to hours, minutes and seconds results in 14:42:45.4. The 0.4 seconds is bogus because I ignored dUT1.

---

Footnotes:

1. There's a problem with using Julian dates to express time when high precision is of concern. The problem is that adding 2.45 million and change to the time since noon on 1 Jan 2000 results in potential truncation problems. The next representable Julian date after midnight 1 Jan 2000 is 40 microseconds after midnight. I myself try to stay a couple of orders of magnitude away from the quantization level, which means problems for dates at the millisecond level.

   Almost every scientific package that supports Julian dates either uses a pair of double precision numbers or uses some sort of modified Julian date, such as time since 12 Noon 16 Nov 1858 (omits the leading 2.4 million in Julian date), time since 12 noon 23 May 1968 (omits the leading 2.44 million), or time since J2000.
2. The term $\Delta t$ in equations (2) and (4) is better known as dUT1. This is the difference between UT1 (time using the mean rotating Earth as a clock) and UTC (time that runs at the same rate as an atomic clock, but with leap seconds occasionally inserted to keep UT1 and UTC in sync). Those leap seconds keep $|\text{UT1}-\text{UTC}| < 0.9\,\text{seconds}$. Simply ignore the $\Delta t$ term if that's the case -- but remember that fractions of a second are meaningless.

> **Comments:**
> **username_0**: Thanks for your comprehensive answer, it did really help! I finally found the problem that was causing wrong coordinate conversion and, unfortunately for this forum, it has fallen in the area of wrong unit conversion and signed operations. I plan to upload my C++ code in order to contribute a little but I'd love to know what would be the current/appropriate model to use if not this outdated one. Could you kindly provide a reference?  
> **username_3**: @CarlesAraguz -- Two references! One is the International Earth Rotation and Reference Systems Service (IERS) Conventions, described in [IERS Technical Note 36](https://www.iers.org/IERS/EN/Publications/TechnicalNotes/tn36.html?nn=94912). Pay particular attention to chapters 4 and 5. The other is the Standards of Fundamental Astronomy (SOFA) open source software maintained by the International Astronomical Union (IAU) at http://www.iausofa.org . If you poke, you'll see lots of functions in C and Fortran, plus some "cookbooks".The cookbook of interest is http://www.iausofa.org/sofa_pn_c.pdf .  
> **username_4**: just a question @David Hammen In equation(3), to convert from radians to sidereal seconds, the expression shouldn't been multiplied by 86164/2π, where 86164 is the number of seconds in one sidereal day? (t−Δt) is in sidereal seconds (even if Δt is ignored), since t(UTC) and Δt(UTC-UT1) And so the result shouldn't be modulo 86164? Sorry but I could not reply with a comment  
> **username_3**: @binghy - Multiplying by $\frac{86164}{2\pi}$ would be incorrect. $(t-\Delta t)$ yields UT1 seconds, not sidereal seconds. (If you already knew the time in sidereal seconds it would be game over; the whole point of this exercise is to convert UTC time to sidereal time.) Multiplying a value in units of $\frac{\text{radians}}{\text{UT second}}$  by $\frac{86400\,\text{UT seconds}/\text{solar day}}{2\pi\,\text{radians}/\text{sidereal revolution}}$ converts that value to units of $\frac{\text{sidereal revolutions}}{\text{solar day}}$. This is equivalent to units of sidereal seconds per UT second.  

---

### Answer by username_1 on 2017-05-12. Score: 3

I worked out the GMST using the method described in http://aa.usno.navy.mil/faq/docs/GAST.php. This should be an authoritative source, and claims 0.1 second accuracy.
In pseudo-code:
midnight = floor(2458484.833333) + 0.5            // J0 = 2458484.5
days_since_midnight = 2458484.833333 - 2458484.5  // = 0.333333
hours_since_midnight = 0.333333 * 24              // H = 8.0
days_since_epoch = 2458484.833333 - 2451545.0     // D = 6939.833333
centuries_since_epoch = days_since_epoch / 36525  // T = 0.190002
whole_days_since_epoch = 2458484.5 - 2451545.0    // D0 = 6939.5

GMST = 6.697374558 
     + 0.06570982441908 * whole_days_since_epoch 
     + 1.00273790935 * hours_since_midnight
     + 0.000026 * centuries_since_epoch**2        //=470.712605328

GMST_hours = 470 % 24 // = 14
GMST_minutes =  floor(0.712605328 * 60) //=42(.7563197)
GMST_seconds =  0.7563197*60 // =45.38

This calculation agrees with the online calculator. The method here (or as described at the link) should be easy to implement.

> **Comments:**
> **username_2**: James - A minor error your pseudo-code: In your final calculation for GMST, you show the variable hours_since_epoch. This should be hours_since_midnight.  
> **username_1**: @RobertSmith  Cured.  

---

