グリニッジ恒星時

    恒星時は天体観測に都合が良い時間だと説明されています。天球の赤経ゼロが天頂を通過するときをゼロとした時間のようです。天球に描かれた恒星は動かないので、同じ恒星時は同じ配置で恒星が見えると言うことだと思います。
  この話しは、ローカルな恒星時の話しです。天頂は観測者の位置の数だけあるのであり、時刻も、それだけ存在します。
  こう考えると、どこにいる観測者も、同じ時刻には、同じ天球の方向を向いていることになります。
  しかし、観測者自身が恒星時を計測していなければ成り立ちません。おそらく、実際には普通の時計や、グリニッジ恒星時から、その場所の恒星時に変換することになります。結局、時計と同様に、「ここでは何時ごろのこと」と考え、場所固有の恒星時を常用している訳ではないと思います。

  グリニッジ恒星時（Greenwich Sidereal Time）は、座標変換に重要です。天球の赤経は、春分点をゼロと定めています。これが、地上の経度ゼロを通過するのがグリニッジ恒星時のゼロ時で、グリニッジ恒星時は地表の経度を表すことになります。
  この話しは、赤道座標系と、ECEF（ECEF:Earth-Centered,Earth-Fixed）座標系の変換と言うようです。

  赤道座標系は、地球の赤道面と、地球の自転軸によって定まる天球の座標系のようです。赤経、赤緯によって位置を示すという説明もありますが、ここでは、XYZ直交座標系と考えます。
  無限遠の恒星を配置する天球は、その場所を赤経、赤緯で表します。しかし、人工衛星や月の位置はXYZ直交座標系の方が適切です。
  赤道座標系の中心は、地心です。地心から春分点へX軸が通ります。Y軸は赤道面にあり、X軸に直交します。

  ECEF座標系は、地球の準拠楕円体に対応した、XYZ直交座標系のことのようです。
  原点は地心にあります。X軸は赤道面にあり経度ゼロへ向かいます。Y軸は赤道面にあり、X軸に直交します。

  2つの座標系は、地球の自転軸を軸として回転しています。一般的には、恒星は動かないと考え、内側のECEF座標系が地球と共に回っているように見るのだと思います。

  現実には春分点も変化しますが、「2000年の春分点を基準に」と言ったようにして、固定して使用されているようです。
  赤道座標系は恒星を基準にしたもので、地球の自転で移動しません。したがって、赤道座標系の点（x0、y0、z0）が与えられると、その位置は時間の関数としてECEF座標系で表されることになります。

ECEF座標系の位置

  赤道座標系とECEF座標系は、グリニッジ恒星時ゼロにおいて重なります。
  赤道座標系の点（x0、y0、z0）が与えられると、グリニッジ恒星時ゼロには、ECEF座標系でも（x0、y0、z0）が座標値となります。
  時間に従って地球が自転し、座標値が変わります。変わるのはX、Yの値で、Zの座標値は変わりません。
  この変化はZ軸の周りに回転する運動です。回転する量は地球の自転速度に時間を乗じた量です。方向は時点と逆向きになります。
  地球の自転速度は、角速度の、7.292115E-5 ラジアン / 秒 が使用されます。この値は定数として使用されており、正確なら良いと言う訳ではないようです。
  地球の自転速度は、恒星時間の1日の長さで決まります。  一日は、86164.091秒（23時間56分4.091秒）と決められているので、計算上は、2π / 86164.091 = 7.2921158156e-05 です。

  グリニッジ恒星時間 T（秒）には、地球はZ軸に θ = -7.292115E-5・T 回転しています。

 と計算されます。

グリニッジ恒星時の計算

  ECEF座標系への変換のためにグリニッジ平均恒星時を計算します。グリニッジ平均恒星時は、そのゼロの時刻には、赤道座標系とECEF座標系が重なっていたことを示し、Z軸の回転量そのものです。
  グリニッジ平均恒星時には決まりがあり、J2000.0 と表記される場合は、2000年1年1月 12:00 における春分点を基準にしていることを示しているようです。
  平均太陽日は86400秒で、平均恒星日は86164.091秒で約236秒の差があります。共にSI単位の秒での表示です。
  2000年1年1月 12:00 のグリニッジ平均恒星時を G0（秒） とすると、平均太陽日でN 日後は、恒星時では G日となります。
  G = G0 / 86400 + (86400 / 86164.091)N
  計算結果を、 国立天文台の計算ページの出力と比較してみましたが、なかなか一致しません。

  ここに上げるR言語のスクリプトは、この章以降の章に書いたようなことを調べ直して、再考した結果です。
  ECEF座標系への変換は、GPS衛星の位置の計算の話しから関心を持った訳ですが、この計算はあまり精度の高いものではないようです。1日の長さは公転に従って変化し、平均より －22秒から+29秒の範囲にあるもので、平均太陽日を使用して計算していること自体が時々の値を正確に知ろうというものでないことを示しています。
  決められた定数を使って計算された価を、他の計算に利用するのが目的なのだと思います。

  暦日表記の時間から、グリニッジ平均恒星時を計算します。グリニッジ平均恒星時は角度で表すことにします。
  平均恒星日はSI単位で 86164.091秒 ですが、恒星時は 86400秒で一回りする通常の24時間表記で表されます。
  つまり、太陽時の1秒 = 86400 / 86164.091 = 1.0027379 恒星時の秒 で、1秒が同じ長さではないと言うことです。
  角度で表す場合は、SI単位の 86164.091秒 で一回りすることで違和感はありません。

  しかし、平均恒星日の 86164.091秒 は小数点以下3桁の8桁の精度なので、とても国立天文台の計算結果の9桁の精度になりません。
  国立天文台の計算ページの値が正確なのかどうかは知りませんが、近い値になるように、平均恒星日を 86164.0905307834764 として計算しました。平均太陽日 / 平均恒星日 = 1.00273790935138 です。

  計算結果は下記のようになります。スクリプトのコメント部分が国立天文台の計算ページの算出値です。
  小数点6桁目で1の差が生じています。

  時刻形式で表示する場合は、恒星日の秒数ではなく、86400秒で一回りするものとして表記されるようです。

  グリニッジ平均恒星時が、基点となるときからの、平均太陽日と平均恒星日の累積値の差であることは確かなようです。
  起点となる 2000年1年1月 12:00 における、恒星時は明確な値が分かりませんが、18.697374558時 のようです。 

地球時、世界時、協定世界時

  世界時、協定世界時（UTC）は、区別なく使用されているようです。世界時はUTC以外にUT1があり、天体や人工衛星の観測から地球の自転の角速度を提供するもののようです。
  UTCには閏秒が適用され、UT1を近似するように運用されてきたようです。

  農耕暦と言うように、暦日は「天象」を表すことに目的があります。「天象」は、天体の運行であり、天候でもあります。
  地球の公転によって定まる節季によって暦が捉えられました。それは、地球の時点によって定まる「日」によって計られました。日は、太陽の正中（正午）の間隔で表されます。時間は日の分け方だと考えられます。

  地球の公転周期と自転周期は独立したことで、直接的な因果関係はありません。また、地球の自転が一定の間隔であることも根拠はありません。
  また、時計の原理と、地球の自転との間にも、直接的な因果関係はありません。
  「SI単位の秒」も、常に同じ間隔を刻んでいるとは考えられていないものと思います。時間は速度や重力の影響を受けると考えられています。

  UTCがUT1を近似するように考えられたのは同時性の問題があると思います。精度の高い天体観測結果は、遠隔地の時間を精度良く定めることができます。しかし、一箇所で生成された時間が電気的速さで世界中に伝えられる状況では重要性がありません。

  UTCが何を示すかより前に、現実にUTCが一般的な時刻であることが重要で、UTCは公共性によって定義されることになると考えられます。1972年から1998年の27年間に22回行われた閏秒は、1999年以降2014年までの16年間では3回しか行われませんでした。
  1年に1秒のズレが一方向に続いたとして、3600年経たなければ1時間のズレにはなりません。
  日常生活においては、地域ごとの標準時が使用され、1時間のズレがあっても許容しています。居る場所の経度によって変わる正確な時間を使用したいとは考えません。時間は位置と共に記録されなければ意味がなくなり、人とのコミュニケーションには向きません。
  UTCがUT1を良く近似するとして、それが有用なことは、あまり考えられません。コンピュータを使って計算をすることが前提になると、天体観測においても打刻はSI単位の秒の積算以外にはないものと思います。
  現在のUTCはSI単位の秒の積算の代わりを務めていて、暦との一致度は必要以上なのだと思います。

  では、SI単位の秒の積算は国際原子時 (TAI)のようです。UTCとTAIは、秒の単位で同期しているようです。
  地球時（TT）もSI単位の秒の積算ですが、TT = TAI + 32.184秒 と言う定義のようです。
  また、GPS衛星は原子時計を搭載し、その放送するGPS時（GPST）は、TAIの変わりに使用されるようです。

閏秒

   1972年1月1日 0:0:0 に、TAIとUTCは10秒差で同期が取られたようです。TAIは1977年に歩度を調整しているので、精密な時間間隔として一定になるのは、それ以降ですが秒のカウンタとしては 1972年1月1日 0:0:0 からを考えて良いものと思います。
  TAIやUTCが実際に、どのように時刻を表しているのかは知りませんが、NTPプロトコルで提供されているカウンタで考えて見ます。
  パソコンが2014年8月20日10時間56分31秒（JST）と表示する時刻の、NTPメッセージのカウンタの整数部は 3617488591 でした。
  1972年1月1日 0:0:0 のカウンタは 2272060800 だったことになります。 

  TAIのカウンタが何時起点なのかは良く分かりませんが、10秒差の 2272060810 と表記しておきます。
  TTも分かりませんが、2272060810 + 32.184 = 2272060842.184 としておきます。

  1972年には、2回の閏秒がありました。その意味は、左表のようなカウンタの推移のことだと思います。

   2012年に25回目の閏秒があり、初期の10秒と合わせて TAI －UTC は 35秒です。
  しかし、これはカウンタの話しであって、暦表示とは無関係です。
  例えば、UTC の 2303683199 、TAI の 2303683209 は、共に 1972年12月31日 23:59:59 を表します。35秒の進みや遅れと言う表現は紛らわしいと思います。ただし、TAI の 2303683210 を、1972年12月31日 23:59:60 と表示すると言うルールはあるようです。

  TAI のカウンタは、SI単位の1秒の積算ですが、UTCのカウンタは25回、2秒で1つとカウントされました。

国際原子時と歩度

  SI単位系の1秒はセシウム133の発生する電磁波の周期で定められています。突き詰めれば時間の間隔が等しいと言うことには明確な根拠はないものと思います。
  国際原子時は、実際に測定を行って時刻を定めるものです。1958年1月1日0時0分0秒 (TAI)が起点で、このときは天体観測に基いた暦日と一致していたことになります。しかし、 1977年に「歩度」が変更されたと記されています。原子時計が計測する値を秒に換算する際の定数が変更されたものと解釈できます。1977年以降の1秒は「同じ長さ」だと考えて良さそうです。国際原子時は、この秒の積算値だと解釈できます。

 暦日と1秒

  昼夜の時間配分は季節によって変動しますが、1日の長さは恒星の観察から、ほぼ一定であると考えられてきたものと思います。
  何時からなのかは分かりませんが、日が24時間で、1時間は60分、１分は60秒と言うことが定着しています。
  このことは、SI単位系の1秒に基いて時間を計るようになっても、何も変わっていません。
  SI単位系の1秒が86400（=24*60*60）が、天象である暦日の1日となる根拠はありません。しかし、SI単位系の1秒のティックを、暦日の秒と同じ方法で表示することが当然のように行われます。
  原子時計が刻む1秒のティックに閏秒の概念があるはずはないのですが、原子時計の時間が修正されるように報道されます。閏秒は、時々、86401秒を1日として、暦日に換算すると言う意味だと思います。

  このことは、同じ原子時計が刻む1秒のティックの値が、2通りの暦表示に換算されることを示します。それは、閏秒の存在を考えた暦日と、機械的に1日が24時間として換算した暦日です。
  前者は、天象である暦日の近似値を得るものです。天象である暦日は、本来は事後にしか定まらないものです。その予測値として、原子時計のティックから計算される日時を使うことは合理的です。しかし、観測結果に振るのは原子時計のティックの方が合理的です。
  多くの時間に依存した物理現象は、原子時計のティックそのものに依存しています。閏秒のときに速度が2倍になったりはしません。

J2000.0

  グリニッジ恒星時には、グリニッジ視恒星時（Greenwich Apparent Sidereal Time）とグリニッジ平均恒星時（Greenwich Mean Sidereal Time）があるようです。
  視恒星時と言うのは、直近の春分点の観測結果に基いて、と言うことだと推測します。
  考えていることが座標変換なので、平均恒星時を考えます。この基準は、J2000.0 と表記されるようです。
  基準となる春分点が経度ゼロでUTCの時刻 T に正中となったと言ってもらえれば理解可能ですが、そうした説明はないようです。
  単に、地球時の 2000年1月1日12:00 のことだと書かれています。
  この時点に春分点が経度ゼロで正中となった、つまり恒星時がゼロだったとも考え難いことです。
  前述の計算では、2000年1月1日12:00 には、グリニッジ平均恒星時が18時間41分50.5484秒 とすると計算が合います。

  2000年1月1日12:00（TT） 、2000年1月1日11:59:27.816（TAI）、あるいは 2000年1月1日11:58:55.816（UTC）の春分点の位置が取り決められていることだと思うのですがその値はなかなか記されていないようです。

  2000年までの閏秒は22回ありました。「閏秒」に示したように、カウンタとしては、初期の10秒を含めて IAT －UTC は32 です。TT － UTC は 64.184 です。同じ暦法に従えば、1つの時点には1つの表記が妥当です。TT、TAI、UTCで表された時点が同じ時点を示すなら、その暦日は1つです。3つの暦日表記は、三種のカウンタの値を、同じルールで暦日に直したら、こうなると言うことであって、何の意味もありません。
  「Julian date 2451545.0 TT」と言う説明は納得できます。ユリウス通日を TT としていて、暦日の 2000年1月1日12:00 にほかなりません。UTCはUT1の近似でもあり同様に、2000年1月1日12:00 です。この時点のグリニッジ平均恒星時は 18.697 374 558時 と言うことのようです。
  2000年1月1日12:00の18.697 374 558時間前に、春分点がグリニッジ（経度ゼロ）で正中となった、あるいは子午線を通過したと解釈できます。 

パソコンの時間

  最近は時間を64ビットの浮動小数点で表すソフトウエアもあります。52ビットの仮数部の精度はms以下の精度があります。また、138億年前や未来も表現可能で、その場合でも日より細かい精度を持っています。遠い時点の表記は荒くて良いとすれば有効な方法です。

  .Net の DateTime.Ticks は、64ビットの整数で、単位が100ナノ秒です。起点は1 年1 月1 日 00:00:00 と説明されています。

  パソコンの時間はネットワークを介してUTCで同期しています。SNTPプロトコルが定める時刻データは64ビット固定小数点数で、秒を単位としています。32ビットの整数部と、32ビットの小数点以下で構成されます。

  パソコンを操作してインターネット時刻の同期を取っておきます。その上で、.Net framework が扱う時間と、NTPメッセージ中の時間を見てみました。

1. 2つのNTPサーバは、秒以上では同じ値を送ってきました。この時間は、41869日1時間56分31秒です。
    3617488591 = 41869*86400 + 1*3600 + 56*60 + 31
2. Net framework の DateTime で表示した 分秒と一致しています。（時間は+9されJSTで表示されています。）
   このことから、 ネットワークで送られている時間はUTCで、閏秒を含んだ値だと分かります。
3. 各プログラミング言語は日時を扱う関数を持っていて、今日（2014-8-20）から41869日前の暦日を計算します。
   

   1. > as.Date("2014-8-20") - 41869
   2. [1] "1900-01-01"
4. NTPで送られるUTCは、1900年1月1日 0:0:0 からのカウントです。2014年8月20日1時間56分31秒までの秒数を積算してみます。まず、日数は、41869日です。
   

   1. > 365 * 114 +   # 平年の日数
   2. + 28 +          # 閏年の回数(1900は閏年でない)
   3. + 231           # 2014 1/1 からの日数
   4. [1] 41869

   したがって、秒の積算値は 3617488591 で、NTPサーバの値と同じです。
   

   1. > ((((4186 * 24) + 1) * 60) + 56) * 60 + 31
   2. [1] 361677391
5. Net framework の DateTime のTicksの値は、100ナノ単位なので秒未満を除いた、63544096591 の部分は、735464日1時間22分31秒です。
   63544096591 = 735464*86400 + 1*3600 + 56*60 + 31
6. 735464日は、グレゴリオ暦のルールで計算した1年1月1日のことです。
   

   1. > d <- 0 # グレゴリオ暦のルールで2013年末までの日数をカウント
   2. > for(i in 1:2013)
   3. + {
   4. +   d <- d + 365
   5. +   if((i %% 4)==0) d <- d + 1
   6. +   if((i %% 100)==0) d <- d - 1
   7. +   if((i %% 400)==0) d <- d + 1
   8. + }
   9. > d + 231 # 2014/1/1以降の日数を加算
   10. [1] 735464
7. 当然、ユリウス暦の1年1月1日ではありません。当然ながら当時使われた暦とは無関係な計算上の日にちです。
   2世紀までは4年後との閏年も正しく運用されておらず、グレゴリオ暦の最初の日の1582年10月15日（金曜日）の前日は、1582年10月4日（木曜日）でした。

  パソコンは和暦でも十干十二支でも変換しますが、その基本はグレゴリオ通日、UTCのTick 、86400秒 / 日 と言ったことのようです。

ユリウス通日

  時間と日は別に考えた方が良いようです。1日の長さには、いろいろな考え方がありますが、日にはほとんど影響していません。どんな暦でも昼ごろが太陽の正中であり、夜中だったりはしません。
  暦日として、どう表現するかには多様な方法がありますが、通日は起点が、どこかしか差がありません。また、負の方向に伸ばしても、問題がありません。
  グレゴリオ通日やユリウス通日と言うのは、通日そのものの差異ではなく、暦日に換算する際の規則に由来します。
  ユリウス通日は、1年を365.25日、1日を 86400秒 / 日 として計算されるので最も良く使われるようです。ユリウス通日に TT と付された記述があり、ユリウス通日は地球時とも見なされています。
  表示も、グレゴリオ暦を指定して変換すればカレンダーに一致させられます。
  厄介なのは、何月何日のユリウス通日は？、と言うときです。この何月何日が、そもそも何暦の何月何日なのかが問題です。

  ユリウス通日の起点は紀元前4713年1月1日正午と定められています。また、ユリウス通日から 2,400,000.5 を引いたものを修正ユリウス通日と呼んでいます。言い換えるとユリウス通日の 2,400,000.5日 が修正ユリウス通日の起点です。
  修正ユリウス通日の起点の暦日は、グレゴリオ暦の 1858年11月17日 0:0:0 です。これは、グレゴリオ暦の最初の日の1582年10月15日（金曜日）より後のことなので、現在のカレンダーと同じ暦法によっています。
  では、ユリウス通日の起点の紀元前4713年1月1日と言うのはどうでしょうか。

  紀元前の閏年も4で割り切れる年として計算しているので正しくはないものと思います。4年と紀元前4年の間は7年になります。

  修正ユリウス通日の起点から、2,400,000.5日遡ると、紀元前4713年1月1日を12日越えてしまうことになります。
  この日数は後述のようユリウス暦からグレゴリオ暦への切り替え時の10日の扱い方が原因です。
  残りの2日は、暦法の差です。
  グレゴリオ暦になった1582年から1858年までの間に100で割り切れる年は、1600,1700,1800と3回ありました。このうち1600年は、400で割り切れるので閏年です。ユリウス暦とグレゴリオ暦で2日の差があります。
  プログラムは一律にユリウス暦のルールで計算していますが、本来は、1582年以降はグレゴリオ暦のルールで計算すべきでした。

ユリウス暦の暦日

  ユリウス暦からグレゴリオ暦への切り替えは1582年10月4日（木曜日）の翌日を1582年10月15日（金曜日）とすることで行われました。
  1582年の1年はカレンダー上で10日短かったことになります。
  前述のユリウス通日の起点の10日間のズレは、このスキップした日数なのだと思います。

  .Net framework の DateTime の返す値は、表のようになります。ユリウス暦もグレゴリオ暦も、実在しない日付を使って、連続した日として、拡張されています。したがって、ユリウス暦でも、グレゴリオ暦でも1582年の1年は365日になります。

  修正ユリウス通日の起点から紀元前4713年1月1日へ遡る計算は、起点をグレゴリオ暦の 1858年11月17日から、同じ日を表すユリウス暦の11月5日に替えると上手く行きます。1858年分の日数が320日から309日になるためです。
  グレゴリオ暦を過去へ延長すると、閏年の処理とは無関係に最初から年初が10日ズレています。1582年10月4日より後に延長したユリウス暦にはズレがありません。
  こうしたことを考えるには通日は重要です。

  1582年のカレンダーでは、10/5から10/14の10日間が使われなかった訳ですが、パソコンが計算するユリウス暦やグレゴリオ暦では、それらの日付も使用しています。
  パソコンが計算するユリウス暦は、1582年10月4日までは実際に使われたカレンダーと一致します。ただし、どこまで遡れるかは定かではありません。
  パソコンが計算するグレゴリオ暦は、1582年10月15日以降は、実際に使われているカレンダーと一致しています。
  グレゴリオ暦を過去へ延長することは、仮想の話しであり、月日は最初からズレています。
  ユリウス暦を1582年10月4日を越えて延長することは、月日がズレているので、計算上の都合以上の意味はないと思います。
  1582年に近い時点ではユリウス暦は普及していたものと思いますが、何時ごろから主要なカレンダーになったのかは分かりません。それだけでなく、1世紀には閏年がルール通りに適用されていないことが知られています。ユリウス暦の始まりは紀元前45年ごろと考えられているようです。これより前のローマ暦には閏年はなかったようです。ユリウス暦も数世紀より前の話しは仮想のものと考えた方が良さそうです。

  なぜ暦日表示をするかを考えると、月日が季節を感じさせることが理由と考えられます。グレゴリオ暦を遡らせることは、これにかなっています。しかし、それは行われません。
  日本の歴史的出来事の年号はユリウス暦に換算して示されます。ユリウス暦が使用される理由は地域や年代によっては、実際に使われた暦と一致するからですが、それが援用されています。計算の容易さもありますが、パソコンが計算するので有意なことかどうかは分かりません。
  朱鳥と言う「元号」は、天武天皇のユリウス暦686年8月14日に制定されたと推定されています。天武天皇の崩御はユリウス暦686年10月1日と見られ、49日間だけ使用されました。日本書紀の天武天皇の在位期間の最後の年の記述が「朱鳥元年春正月壬寅朔癸卯」となっていて、その「秋七月」の「戊午」に改元が記されています。64年周期の十干十二支で年が示され、朔の日が添えられたことから年月日を特定されたものと思います。しかし、日本書紀の記述の信頼性などは分かりません。
  ユリウス暦686年8月14日はグレゴリオ暦の8月17日に相当します。「秋」と言う記述を考えると3日の差も大きな気がします。
  「閏年」に上げた表のように1582年10月4日の日をユリウス暦とグレゴリオ暦で表すと、グレゴリオ暦の方が10日大きな値に表されます。ユリウス暦の方が多く閏年をカウントするので、1世紀には差がなくなります。686年では3日の差と言うことです。
  日本では1872年（明治5年）にグレゴリオ暦が採用されました。この時点での差は12日でした。幕末の和暦はどのように西暦表示されているのか良く知りません。

恒星日

  通常、1日は太陽の正中から正中までの時間で、公転の影響によって、自転の１回より少し長く回ることになります。この話しは、地球の自転一回を、太陽で計るか、恒星で計るかの違いです。
  天球上の位置で扱えば、地球の自転を除いて考えられます。
  天球は、恒星が、ほぼ無限遠にあることを前提に、距離を無視して、球面上に恒星を配置します。天球上の位置は、赤経、赤緯で表されます。
  赤経の基準は、春分点と決められています。赤緯は地球の赤道面を基準としています。

  太陽の正中から正中までの平均太陽日は、SI単位系の86400秒（24時間）より１から2ms長いと言うことです。1日の長さは公転に従って変化し、平均より －22秒から+29秒の範囲にあるようです。

  平均恒星日は 86164.091 秒で、SI単位系の86400秒（24時間）より約236秒短いようです。
  経度ゼロ（グリニッジ）における子午線を、春分点は  86164.091 秒周期で通過すると考えて良いものと思います。
  春分点と地心を結ぶ直線は、地球の赤道面上にあり、地心を中心に、86164.091 秒に1回の速さで回っています。これがグリニッジ平均恒星時なのだと思います。

  GPS衛星の軌道計算では、地球の自転の速さは、7.292115E-05 rad/s と言う定数を使って計算されます。2π / 7.292115E-05 = 86164.10 です。地球の自転の角速度は、恒星日を 86164.1 秒として算出しているようです。

  良く分からないのは、恒星時の秒です。SI単位の秒なら86164.091 秒で一回りとなります。しかし、何も述べられていないのは恒星時も以下のように扱っているからだと解釈して置きます。
  360° = 24時間 = 86400秒

  暦日で N 日経過したときの、グリニッジ平均恒星時の変化量は、平均太陽日のカウントである N を、平均恒星日のカウント M に直すことです。
  M = N * (平均太陽日の長さ / 平均恒星日の長さ) = 1.0027379・N

  比 1.0027379 で計算することができます。ただし、暦日の1日は閏秒によって、SI単位の秒で 86401秒 のことがあります。
  したがて、計算対象の期間が閏秒の適用日を含む場合、その秒数だけ、SI単位での時間は長いことになります。
  しかし、平均太陽日も平均恒星日も平均値であって、その値そのものが暦日の時間に合うように計算されたものと考えられます。
  UTCのカウンタは、UT1の近似するものであり、閏秒による調整は不要だと思います。

  1.0027379 と言う値は、恒星日が小数点以下が3桁の値から計算したものです。恒星日は、86164.09054 がより精度の高い値らしく、この値の場合、1.002737909 となります。
  この値の精度は、影響が大きいのでプログラムでは 1.00273790934 が使われているようです。その場合、恒星日は、86164.09053176 と言うことになります。
  この値は、恒星時の1秒をSI単位の1秒で表した値でもあります。ほぼ、太陽平均時の1秒で表した値でもあります。
  その値は、2000年には 1.002737909350795 秒で、千年後には 1.002737909409795 になると言った値のようです。
  国立天文台のグリニッジ恒星時計算のように、ミリ秒の精度で計算するには、平均太陽日と平均恒星日の比の値が16桁必要だと思います。

  国立天文台のグリニッジ恒星時計算は「小数点表示」を選ぶと「度」で恒星時を表示します。
  例は、21h 41m 11.046s = 325.296027° です。 

  恒星時の1日は86164.091 秒で、SI単位の86164.091でゼロに戻ります。おそらく、恒星時の表示は、この時間を86400秒として、普通の24時制の表示をします。
  角度はSI単位の86164.091秒 を 360° としていると考えられます。
  時間表示では86165秒以上が欠番になったり、360°まで使われなかったりしている訳ではないと考えます。