[5] ambtime は、「3分前」や「9年3ヶ月前」のような現在時刻からの相対時刻による日時表示です。
[6] 閾値を設けてそれ以上離れた日時は通常の絶対時刻の日時形式にする場合もあります。
[7] 現在までの時間経過を (時差のことも考えずに) 瞬時に把握するのに便利だとして、 SNS をはじめとする多くの Webアプリケーションで採用されています。
[8] Web 上では、絶対時刻も知れないと不便であるとして、title
属性のツールチップのような形で絶対時刻と併記することが多々あります。
[20] 表示が随時更新されず、最初の表示時点のもののままになっていることもあり、 要注意です。
[1] gist: 120040 - GitHub ( 版) http://gist.github.com/120040#L43
[2] 過程と模索、その1つのサンプル ( 版) http://ameblo.jp/ksy-dev
[4] 2009-12-11 - ある1つのサンプル ( ( 版)) http://d.hatena.ne.jp/ksy_dev/20091211#p1
[18] PHPでのAmebaなう更新情報の取得 - ある1つのサンプル () https://web.archive.org/web/20100505173109/http://d.hatena.ne.jp/ksy_dev/20091211/p1
[3] gist: 163197 - GitHub ( 版) https://gist.github.com/163197/2ae5a503c519343a026a082eb07938792ff238d2
[10] なぜTwitterは相対時刻表記を求めるのか ( ()) http://anond.hatelabo.jp/20120916100440
[11] NSDate を相対時刻にするライブラリ - 大学生からの Web 開発 ( ()) http://karur4n.hatenablog.com/entry/2015/06/24/004136
[12] datetime属性を持つtime要素を全部相対時刻にするやつ ( ()) https://gist.github.com/hail2u/8d96d6ed7fc5995f6e7c292dfef1fe6c
[13] time要素の中身を相対日時へ変換 - ウェブログ - Hail2u.net ( ()) https://hail2u.net/blog/converting-time-element-content-to-relative-date.html
[14] 数時間程度の時刻の表示で時差を無視して考えられて理解しやすいというのは正しいですが、 「昨日」や「3日2時間前」のような微妙な遠さの時刻だと日界が気になってしまいます。 「4ヶ月前」や「1年前」くらいまでいくと最早誤差になりますが、 そこまで多いと絶対時刻表記にしたくなるので、時差からは逃れられません。
[15] Announcing Windows 10 Insider Preview Build 18305 | Windows Experience Blog () https://blogs.windows.com/windowsexperience/2018/12/19/announcing-windows-10-insider-preview-build-18305/
[16] Windows 10 Insider Previewでテスト中の日常的な日時表現、どう思う? | スラド IT () https://it.srad.jp/story/19/03/10/0428225/
Thank you for all of the feedback you provided on Friendly Dates in File Explorer. At this time, we’ve decided not to roll out Friendly Dates to users as part of the 19H1 release. Insiders will see this option go away starting today, regardless of build number.
[19] 山手線などの駅のホーム上におけるご案内を充実します! ~発車標に列車が駅に到着するまでの時間「約○分後」の表示を実施します~ ~発車標をLCD化(液晶ディスプレイ化)します~ ~英語案内放送を拡充します~ () https://www.jreast.co.jp/press/2019/tokyo/20191015_1_to.pdf
[21] より良い相対日時表記についての考察 - シフトブレイン/スタンダードデザインユニット () https://standard.shiftbrain.com/blog/relative-datetime
[22]
time.js は、一定以上離れた日付は通常の絶対日時表示にするモードを
data-format=ambtime、
常に相対的な表示にするモードを
data-format=deltatime
と呼んでいます。
[23] dayjs/Plugin.md at dev · iamkun/dayjs · GitHub, https://github.com/iamkun/dayjs/blob/dev/docs/en/Plugin.md#relativetime
[24] Time from now · Day.js, , https://day.js.org/docs/en/display/from-now
[25] Relative Time · Day.js, , https://day.js.org/docs/en/customization/relative-time
[26] 欧米サービス、 Instagram などは日の次の単位が週になってるみたいですね。 何年も前なのに「何週間前」と書かれてもいつなのか全然イメージがつかないのですけど、 週をよく使うと言われる欧米人には馴染み深い表記なんですかねえ?
[27] というところがあるので、結局回避できるのは直近の数時間程度の時差違いの問題だけで、 その他の文化的要素はよくよく考えないといけないんですよね。
[28] でもなんとなくその辺考えなくてもいいような誤解を与えてしまうのが、この形式の罪深いところではないでしょうか。
[29]
ロケール処理という意味だと実は結構難しくて、何分前みたいな単位の部分を単数形にするか複数形にするか、
というのを言語ごとにちゃんとしないといけない (言語によってはすごく面倒
[30] ウェブサービスなどで、クライアントとサーバーの時計がずれていて、 投稿時刻が「1分後」のように表示されちゃう、という変なやつをたまに見かけます。 そんなの多くないだろ!と思いそうですけど、意外とよく見ます。
[31] そういう場合10中8,9はクライアントの時計が狂ってるんですけど、稀にサーバーの時計が全然狂ってるじゃん、ってこともあります。 普通はサーバーの時計こそ狂わない (ちゃんとした技術者がちゃんと設定してるので。) ものなんですけどね。偶発的なトラブルではなく偶発的にサーバーの時計が狂っているとしたら、 それはサービスの品質がなにかの犠牲になっている、ということです。 そういうのがこういう細かいところに表れてくるんですね。
[32] 投稿時刻が未来になることなんてありえないから、 「後」になるものは全部一律で「たった今」みたいな表示にしちゃえばこの問題は解消するのでしょうけど、 大抵は 「投稿時刻」 専用ではなく汎用の日時表示処理を通しているから、あり得ない「後」の表示がちゃんと用意されちゃってるんですよね。
[33] まあ未来がありえない ambtime の用途が相当大部分を占めてそうなので、 それ専用の処理を用意しておいても損はないかなあという気もしますけど。
[34] ただ、たいてい過去だけどたまに未来、というケースに不具合を生んじゃう温床になりそうなのと、 クライアントの時計が狂っているというそもそも異常な場合にしか発生しないものなので、 そのためにわざわざ対策するのもちょっとなあ、という気持ちもありますね。
[35] XユーザーのM4y4さん: 「mixiのつぶやきが、543年前って表示されてるから、アセった!タイ暦になっていたからでした!」 / X, , https://x.com/mayang_island/status/64545232078897152