[MFM]タイムスタンプ埋め込み構文 Syntax for timestamps

[MineCake147E]

Summary

投稿において、イベントの開始・終了等の日付・時刻を記す際に「明日 23:34」「12月6日 午後11時34分」のように日付や年を明示的に指定しなかったり、日時がほぼ一意に指定されていても「2445年12月6日 23時34分45秒」のようにタイムゾーンを指定せずに投稿するケースがほとんどです。
日付やタイムゾーンが明確でない場合でも、同じ地域に住み同じ言語を話す人なら理解は容易です。しかし、海外在住者や異なる言語を第一言語とする人等は、投稿者の所在地或いは言語から推測する必要がある等の手間がかかり、投稿の言語を自力解読出来ない場合は機械翻訳に頼る必要があります。その結果、正確な日時を特定できないこともありえます。

Discordではそうした問題を解決するべく、<t:15018964485> → のようにタイムスタンプを埋め込む機能が実装されているようです。
https://discord.com/developers/docs/reference#message-formatting

年月日やタイムゾーンまでの詳細な指定をしない人を責めるつもりは一切ありません。
投稿時にタイムゾーンまで気にする人はほぼいないと言っても過言ではなく、私自身も例外ではありません。
そもそもタイムゾーンまで指定したところで、その投稿の言語を自力解読出来ない人に対する言葉の壁は依然として残されます。(極端な例: 「日本標準時 令和四百弐拾七年壱拾弐月六日 午後壱拾壱時参拾四分四拾五秒」等)
言葉の壁がなかったとしても、タイムゾーンを変換する必要があるかもしれません。
しかし、先述したDiscordの機能は閲覧者の言語及びタイムゾーンに合わせて表示するため、言葉の壁も手動変換の手間も取り払ってくれます。
そのため、同様の機能がMisskeyに追加されればいいなと思いました。

提案構文

$[timestamp.style=STYLE TIMESTAMP]
$[ts.s=STYLE TIMESTAMP]
TIMESTAMP: UNIX時刻 or ISO8601?
STYLE: スタイル(後述)(optional)

STYLEの提案書式

STYLE	表示例(参考)	説明
shortTime, t	23:34	短い時間表記
longTime, T	23:34:45	長い時間表記
shortDate, d	2445/12/06	短い日付表記
longDate, D	2445年12月6日水曜日	長い日付表記
shortGeneral, g	2445/12/06 23:34	短い日付+短い時間表記
longGeneral, G	2445/12/06 23:34:45	短い日付+長い時間表記(デフォルト)
shortFull, f	2445年12月6日 23:34	長い日付+短い時間表記
longFull, F	2445年12月6日 23:34:45	長い日付+長い時間表記
sortable, s	2445-12-06T23:34:45	yyyy'-'MM'-'dd'T'HH':'mm':'ss
iso8601, i	2445-12-06T23:34:45+09:00	yyyy'-'MM'-'dd'T'HH':'mm':'ssK
shortRelative, r	422年後	大まかな相対表記
longRelative, R	154160日0時間40分54秒後	正確な相対表記

利点

• fn系MFM構文のパース処理をある程度流用できる
• 閲覧者のタイムゾーンに合わせて表示するため、閲覧者による手動変換の必要がない
• ホバーやタップ等の操作で違う表記での日時を吹き出し表示する機能など、拡張の余地がある

欠点

• 相対表記のフォーマットを言語ごとに書く必要がある
  • EDIT: 過去の大まかな相対表記にはMkTimeのコードを利用できるそうです
• クライアントの開発言語や使用ライブラリ等による表記の違いを許容するべきかどうかは議論の余地がある
  • 表記の違いを許容する場合、クライアントの実装コストは低い場合が多い
  • 表記の違いを許容しない場合、クライアントの開発言語や使用ライブラリ等によって、表示ロケールごとにカスタム書式指定子を書く必要がある可能性が高い
• UNIX時刻をツール無しで計算するのは非常に大変(TIMESTAMPにUNIX時刻を採用する場合)
  • 他のフォーマットでの入力を許す?(ISO 8601等)
  • 投稿フォームに挿入機能を設ける?(別Issue?)

[kakkokari-gtyih]

相対表記のフォーマットを言語ごとに書く必要がある

これに関してはすでにMkTimeコンポーネントがあるのでなんとかなる

[MineCake147E]

misskey/packages/frontend/src/components/global/MkTime.vue

Lines 44 to 54 in 28e394e

	return (
	ago >= 31536000 ? i18n.t('_ago.yearsAgo', { n: Math.round(ago / 31536000).toString() }) :
	ago >= 2592000 ? i18n.t('_ago.monthsAgo', { n: Math.round(ago / 2592000).toString() }) :
	ago >= 604800 ? i18n.t('_ago.weeksAgo', { n: Math.round(ago / 604800).toString() }) :
	ago >= 86400 ? i18n.t('_ago.daysAgo', { n: Math.round(ago / 86400).toString() }) :
	ago >= 3600 ? i18n.t('_ago.hoursAgo', { n: Math.round(ago / 3600).toString() }) :
	ago >= 60 ? i18n.t('_ago.minutesAgo', { n: (~~(ago / 60)).toString() }) :
	ago >= 10 ? i18n.t('_ago.secondsAgo', { n: (~~(ago % 60)).toString() }) :
	ago >= -1 ? i18n.ts._ago.justNow :
	i18n.ts._ago.future);
	});

これを見る限り、未来の日付に対しては「未来」とだけ表示するようです。
イベントの開始時間告知は、投稿時点では未来の日時であることが多いので、未来に対する相対表記をどうするべきかは別途考える必要があると思われます。

[kakkokari-gtyih]

未来の時刻の翻訳入れてpropsで出し分けすればなんとかなる

[yuriha-chan]

世界中どこででも、10分後は10分後なので、相対表記は不要ではないかと思います。
また、MkTimeは現在時刻に対する相対時刻を表示しますが、普通、投稿時刻に対する相対時刻と解釈すると思うので、不適当と思います。（「10分後に始めます！」という投稿をあとから見返したとき、「42571分前に始めます！」と表示されたら変です。）
英語圏など複数のタイムゾーンにまたがるのが自然なコミュニティにおいて、タイムゾーンを自動で変換してくれたら便利という観点で考えるのが良いのではないかと思います。連合のことを考えると、以下のような、見た目がシンプルな形態のほうが良いのかなと思います。

$[time.tz=JST 07:32] $[datetime.tz=JST 2023-10-01 07:32]
と入力し、

これを例えばUTC, en-GBの人が表示すると、
22:32 UTC 30 Sep. 2023 22:32 UTC (自動変換しましたよー、という意味でタイムゾーンを明記する）
JSTの人が表示すると、
07:32 2023/10/01 7:32
となるような感じが良いのではないでしょうか。

[MineCake147E]

世界中どこででも、10分後は10分後なので、相対表記は不要ではないかと思います。
また、MkTimeは現在時刻に対する相対時刻を表示しますが、普通、投稿時刻に対する相対時刻と解釈すると思うので、不適当と思います。（「10分後に始めます！」という投稿をあとから見返したとき、「42571分前に始めます！」と表示されたら変です。）

そのような場面においては絶対表記との併用を前提としており、この場合単独で使用されることを想定していません。
また、過去の出来事であると一目でわかることは、相対表記機能の目的の一つです。
オーディション等の参加締切や期間限定商品の販売期間の終わりなど、「その日時を過ぎているか」を瞬時に判別できることが重宝される場面は結構あります。

「42571分前に始めます！」と表示されたら変です。

MkTimeのコードをそのまま利用する場合、「1ヶ月前に始めます！」などのように表示されることになると思われます。
「42571分前に始めます！」という表示は確かに変ですが、「1ヶ月前に始めます！」という表示が変だとは私は思いません。

連合のことを考えると、以下のような、見た目がシンプルな形態のほうが良いのかなと思います。

$[time.tz=JST 07:32] $[datetime.tz=JST 2023-10-01 07:32] と入力し、

これを例えばUTC, en-GBの人が表示すると、 22:32 UTC 30 Sep. 2023 22:32 UTC (自動変換しましたよー、という意味でタイムゾーンを明記する） JSTの人が表示すると、 07:32 2023/10/01 7:32 となるような感じが良いのではないでしょうか。

自然言語に寄り添うようなこの構文がどのような書式を受け入れるべきか議論する必要があります。
ISO 8601 (例: 2445-12-06T23:34:45+09:00)のような形式のみを受け入れる等であればクライアントの実装は比較的容易ですが、他の自然言語的な入力を許容する場合、الأربعاء، 6 ديسمبر 2445 11:34:45 م(ar-EGで2445-12-06T23:34:45+09:00)などという入力をどうパースするべきでしょうか。

[CyberRex0]

ローカライズを考えるとややこしいのでUNIXタイムスタンプだけでいいと思います
変換に関してはツールを紹介・用意してあげることで簡単に対応できると思います

[syuilo]

$[timestamp.style=STYLE TIMESTAMP]で良さそう

[yuriha-chan]

マストドンなどと連合したときに読解不能になるのは申し訳ないのでISO 8601がよいと考えます。

[yuriha-chan]

「1ヶ月前に始めます！」という表現もやはり変だと思いますが、「締切は22:00(1ヶ月前)です。」という使い方なら、たしかにありかもしれませんね。

[u1-liquid]

エンジニア目線だとUNIXタイムスタンプがいいと思う人もいるかもしれませんがそもそもUNIXタイムスタンプは人間が読み書きする目的の表記方法ではないのでMFMでUNIXタイムスタンプを使うようにするのは一般向けには不親切な設計だと思います

[MineCake147E]

確かに外部ツールなしで現実的に書き込めるのはISO 8601の大きな利点ですね。

[KawaneRio]

English

(Regarding about how UNIX timestamp can be hard to read/write for the general public)

Half of the general public doesn't even know what MFM is. They just use Misskey to socialize. I am a firm beliver that this timestamp function is not intended for the general public who make notes like "Heyy, let's meetup at 7:00 tomorrow😉" but instead, are for the Event Staff, Streamers, Notification bots, and creators alike who wants to display a common time worldwide.
For this purpose, $[timestamp.style=STYLE TIMESTAMP] format has a regular syntax and is excellent for making notification bots to print out certain time. And, as CyberRex0 had mentioned, for those who do not understand UNIX-time, there are plenty of conversion tools available, both online and offline.

If there are anything vital to consider about this, it'll be what yuriha-chan said about parsing the timestamp to outside SNS': when MFM fails for non-misskey instances (e.g. Mastodon), the note would likely display the raw UNIX-timestamp, which would look like $[timestamp 1699604496]. This is not only helpless but it actually defeats the primary purpose of implementing this entire function in the first place: "To display a common time all around the world".

日本語

MFMでUNIXタイムスタンプを使うようにするのは一般向けには不親切な設計だと思います

一般人《いっぱんじん》はMFMの大抵《たいてい》の構文《こうぶん》さへ知《し》らないし、そもそもこのtimestamp機能《きのう》は「明日《あす》7時に集合《しゅうごう》なー」みたいなノートをする一般人《いっぱんじん》向けのものではなく、全世界《ぜんせかい》で共通《きょうつう》の時刻《じこく》を表示《ひょうじ》することを求める《も》とめる主催者《しゅさいしゃ》さんや配信者《はいしんしゃ》さん、通知bot《つうちボット》といった、明《あき》らかに一般《いっぱん》では無《な》い方《かた》へ向《む》けた機能《きのう》だと我《われ》は思《おも》ひます。また、$[timestamp.style=STYLE TIMESTAMP]形式《けいしき》は不規則性《ふきそくせい》がなく非常《ひじょう》に扱《あつか》いやすい（botなどを作《つく》りやすい）ですし、CyberRex0《サイバーレクス》さんも言《い》ってますが、変換《へんかん》ツールはいくらでもあります。

ただ、yuriha-chanのいう通《とお》り、非《ひ》Misskeyインスタンスでの表示《ひょうじ》がUNIX通秒《つうびょう》になるのはあまり好《この》ましくないのも事実《じじつ》です。これだと「世界中《せかいじゅう》の人に共通《きょうつう》した時刻《じこく》を表示《ひょうじ》させる」といった大目的《だいもくてき》が失われてしまいます。むづかしいです...

[MineCake147E]

私なりに少し整理してみます。

UNIX通秒

利点

• パースが楽
  • 多くの言語やライブラリで実装されている
• 外部ツールやGUI補助があれば入力できる

欠点

• Misskey以外のAP対応サービスやtimestamp構文非対応のクライアントでは読めない
  • 閲覧者がその数字をUNIX時刻だと認識できる?
    • 認識できたとしても、外部ツールを使わせることになる
• 1970-01-01T09:00:00+09:00以前の日時は負数になってしまう
  • 負のUNIX時刻を正しく扱える環境がどれほどあるかは未知数
• 外部ツールなしでは手入力がほぼ出来ない
• 一般ユーザーにはあまり馴染みがない

ISO 8601 (yyyy'-'MM'-'dd'T'HH':'mm':'ssK)

利点

• パースが比較的楽
  • ISOにより標準化されている
  • 多くの言語やライブラリでパース処理が実装されている
• 非対応クライアントやMisskey以外のAP対応サービスでも比較的読みやすい
• 手入力が現実的に可能である

欠点

• UNIX通秒よりはパース負荷が比較的大きい?

[slofp]

一般ユーザーにはあまり馴染みがない

UNIX通秒よりは読みやすいものの、一般ユーザーにはあまり馴染みがない

どちらにせよ一般ユーザーには馴染みがないの...

ならいっそMFMではなくノート自体をアンケートみたいに時刻が指定されているノートみたいにしたら良いと思いました。

こういうの

これであればUIから時間指定ができるので少なくとも一般ユーザーの馴染みが無いという部分が消えるのではと...

(まあこれではmfmでなければAPの問題も置き去りにしてるので本末転倒といった感じかもしれないですが)

[kakkokari-gtyih]

ならいっそMFMではなくノート自体をアンケートみたいに時刻が指定されているノートみたいにしたら良いと思いました。

そこまでやるなら #10628 の実装を進める形で解決するのがいいのでは

[slofp]

(すでにあるんだ...)

私はそれでの解決が一番いいんじゃないかなと思いました。。。

そのほうがユーザーにとっては直感的じゃないかなと

[MineCake147E]

そこまでやるなら #10628 の実装を進める形で解決するのがいいのでは

#10628 もかなり魅力的な機能ではありますが、一投稿あたり一つのイベントしか添付出来ないようです。
また、タイムスタンプ構文の使い途はイベント告知だけではなく、年表等過去の出来事を紹介する際に使うこと等も想定しています。
イベント機能とタイムスタンプ構文は別々に実装したほうが良いと思います。

[syuilo]

そのままUNIXTIMEが表示される

[mattyatea]

[syuilo]

Misskeyならunixtimeが解釈されて日時に変換されて表示される