@tateisu @TOCATTI 現状のUTCの日時表現に、タイムゾーンZを末尾につけてもらえれば曖昧さがなくなるので、それがベストかと。

Mastodon本家はRailsのto_datetimeを、今回FedibirdではRailsのto_timeを使っていたのですが、タイムゾーンがついてない場合の挙動が異なり、前者はUTCで解釈、後者はローカルタイムで解釈となっています。

@noellabo @TOCATTI あーやはりそのあたりを変更してましたか…。Zの付与はissueたてて検討します。 https://github.com/tateisu/SubwayTooter/issues/163

@tateisu @noellabo
銀河丼及びPhotodnもAPIに準拠するよう解釈しているのかな···​
Subway Tooter側がPOST時にタイムゾーンを付与するよう改善されたら問題は解消しそうです．(それはインスタンス管理者の分掌ではないですけども)

お調べいただきありがとうございました🙇‍♂️

@TOCATTI @noellabo そもそもAPIにはタイムゾーンなしの場合にどうするという記載はないし、ISO8609でもタイムゾーンなしの日時指定は許容されてるのです。「クライアントがタイムゾーンを省略した際にサーバ側のローカルのタイムゾーンで解釈される」という改造は別に何かに準拠してる訳でもありません。

@TOCATTI @noellabo むしろ国際化の観点ではUTCで統一されてた方が良いまであるので、Fedibirdの今回のは「ああ単一国向けサーバなんだな」という印象があります。

@tateisu @TOCATTI まあ印象については感想ですのでそのまま受け止めますが、単一国向けとする意図はありません。目下、国際化の作業中です。

ISO 8601でタイムゾーンを指定しない場合の解釈は、ローカルタイムとするのが正しいように思われます。原本の規格書をあたろうとしているのですが、高いですね……。

rubyがDateTimeをdeprecatedとしてTimeに移行しており、Time.iso8601がタイムゾーンなしをローカルタイムとして解釈すること、momentや、今回採用したdate-fnsなどでも同様に解釈をすることもあり、to_datetimeの使用・仕様は見直した方がよいと考えています。

まぁ、いずれにしても非互換は適切ではないため、本家の挙動にあわせます。変更が必要な場合は本家の方で対応します。

@noellabo @TOCATTI 「サーバ側の」ローカルタイムに合わせる利点はそれこそ単一国向けサーバにしかないと思います。MastodonはそのあたりAPIの入力も出力もむしろUTCで統一してますね。

@tateisu @TOCATTI そのあたりを踏まえると、「ISO 8601で解釈するが、タイムゾーンがない場合はUTCとみなす」と本家のAPI仕様に注釈明記する方向が良さそうですね。