Edit

Page

Page title:

Page body:

[5] [DFN[ambtime]] は、「3分前」や「9年3ヶ月前」のような[[現在時刻]]からの[[相対時刻]]による[[日時表示]]です。

[6] [[閾値]]を設けてそれ以上離れた[[日時]]は通常の[[絶対時刻]]の[[日時形式]]にする場合もあります。

[7] 現在までの時間経過を ([[時差]]のことも考えずに) 瞬時に把握するのに便利だとして、
[[SNS]] をはじめとする多くの [[Webアプリケーション]]で採用されています。

[8] [[Web]] 上では、[[絶対時刻]]も知れないと不便であるとして、[CODE(HTMLa)@en[title]]
[[属性]]の[[ツールチップ]]のような形で[[絶対時刻]]と併記することが多々あります。

[FIG(short list)[ [9] [[ambtime]] の採用例
- [[Twitter]]
- [[GitHub]]
- [[Facebook]]
- [[Windows]] ([DFN[friendly dates]])
- [CODE[time.js]]
]FIG]

[20] 
表示が随時更新されず、最初の表示時点のもののままになっていることもあり、
要注意です。

[1] [CITE@en[gist: 120040 - GitHub]]
([TIME[2010-01-05 21:43:37 +09:00]] 版)
<http://gist.github.com/120040#L43>

[2] [CITE@ja[過程と模索、その1つのサンプル]]
([TIME[2010-01-05 21:44:25 +09:00]] 版)
<http://ameblo.jp/ksy-dev>

[4] [CITE[2009-12-11 - ある1つのサンプル]]
( ([TIME[2013-04-19 07:35:47 +09:00]] 版))
<http://d.hatena.ne.jp/ksy_dev/20091211#p1>

[18] [CITE[PHPでのAmebaなう更新情報の取得 - ある1つのサンプル]] ([TIME[2019-03-10 21:22:32 +09:00]]) <https://web.archive.org/web/20100505173109/http://d.hatena.ne.jp/ksy_dev/20091211/p1>

[3] [CITE@en[gist: 163197 - GitHub]]
([TIME[2010-01-05 21:48:26 +09:00]] 版)
<https://gist.github.com/163197/2ae5a503c519343a026a082eb07938792ff238d2>

[10] [CITE[なぜTwitterは相対時刻表記を求めるのか]]
( ([TIME[2017-03-31 11:26:03 +09:00]]))
<http://anond.hatelabo.jp/20120916100440>

[11] [CITE@ja[NSDate を相対時刻にするライブラリ - 大学生からの Web 開発]]
( ([TIME[2017-03-31 11:27:15 +09:00]]))
<http://karur4n.hatenablog.com/entry/2015/06/24/004136>

[12] [CITE@en[datetime属性を持つtime要素を全部相対時刻にするやつ]]
( ([TIME[2017-03-31 11:27:37 +09:00]]))
<https://gist.github.com/hail2u/8d96d6ed7fc5995f6e7c292dfef1fe6c>

[13] [CITE@ja[time要素の中身を相対日時へ変換 - ウェブログ - Hail2u.net]]
( ([TIME[2017-03-30 08:43:28 +09:00]]))
<https://hail2u.net/blog/converting-time-element-content-to-relative-date.html>

[14] 数時間程度の時刻の表示で[[時差]]を無視して考えられて理解しやすいというのは正しいですが、
「昨日」や「3日2時間前」のような微妙な遠さの時刻だと[[日界]]が気になってしまいます。
「4ヶ月前」や「1年前」くらいまでいくと最早誤差になりますが、
そこまで多いと[[絶対時刻]]表記にしたくなるので、[[時差]]からは逃れられません。

[15] [CITE@en-US[Announcing Windows 10 Insider Preview Build 18305 | Windows Experience Blog]]
([TIME[2019-03-10 21:09:00 +09:00]])
<https://blogs.windows.com/windowsexperience/2018/12/19/announcing-windows-10-insider-preview-build-18305/>

[16] [CITE@ja[Windows 10 Insider Previewでテスト中の日常的な日時表現、どう思う? | スラド IT]]
([TIME[2019-03-10 21:09:05 +09:00]])
<https://it.srad.jp/story/19/03/10/0428225/>

[FIG(quote)[
[FIGCAPTION[
[17] [CITE@en-US[Announcing Windows 10 Insider Preview Build 18890 | Windows Experience Blog]]
([TIME[2019-05-04 16:54:29 +09:00]])
<https://blogs.windows.com/windowsexperience/2019/05/01/announcing-windows-10-insider-preview-build-18890/>
]FIGCAPTION]

> 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.

]FIG]

[19] [CITE[山手線などの駅のホーム上におけるご案内を充実します! ~発車標に列車が駅に到着するまでの時間「約○分後」の表示を実施します~ ~発車標をLCD化(液晶ディスプレイ化)します~ ~英語案内放送を拡充します~ ]]
([TIME[2019-10-15 16:06:11 +09:00]])
<https://www.jreast.co.jp/press/2019/tokyo/20191015_1_to.pdf>

[21] [CITE@ja[より良い相対日時表記についての考察 - シフトブレイン/スタンダードデザインユニット]]
([TIME[2019-11-08 13:14:31 +09:00]])
<https://standard.shiftbrain.com/blog/relative-datetime>

[22] 
[CODE[time.js]] は、一定以上離れた日付は通常の[[絶対日時]]表示にするモードを
[CODE[data-format=[[ambtime]]]]、
常に相対的な表示にするモードを
[CODE[data-format=[DFN[[[deltatime]]]]]]
と呼んでいます。

[23] [CITE@en[dayjs/Plugin.md at dev · iamkun/dayjs · GitHub]], [TIME[2020-12-31T05:55:49.000Z]] <https://github.com/iamkun/dayjs/blob/dev/docs/en/Plugin.md#relativetime>

[24] [CITE@en[Time from now · Day.js]], [TIME[2020-12-29T03:12:03.000Z]], [TIME[2020-12-31T06:03:27.477Z]] <https://day.js.org/docs/en/display/from-now>

[25] [CITE@en[Relative Time · Day.js]], [TIME[2020-12-29T03:12:03.000Z]], [TIME[2020-12-31T06:08:24.044Z]] <https://day.js.org/docs/en/customization/relative-time>

[26] 
欧米サービス、 [CITE[Instagram]] などは[[日]]の次の単位が[[週]]になってるみたいですね。
何年も前なのに「[VAR[何]]週間前」と書かれてもいつなのか全然イメージがつかないのですけど、
[[週]]をよく使うと言われる欧米人には馴染み深い表記なんですかねえ?
[TIME[2024-01-21T11:21:10.500Z]]

[27] 
というところがあるので、結局回避できるのは直近の数時間程度の[[時差]]違いの問題だけで、
その他の[[文化的要素][ロケール]]はよくよく考えないといけないんですよね。

[28] 
でもなんとなくその辺考えなくてもいいような誤解を与えてしまうのが、この形式の罪深いところではないでしょうか。

[29] 
[[ロケール]]処理という意味だと実は結構難しくて、何分前みたいな単位の部分を[[単数形]]にするか[[複数形]]にするか、
というのを[[言語]]ごとにちゃんとしないといけない ([[言語]]によってはすごく面倒 [SEE[ [[複数形]] ]]) 
というのもあるんです。

[30] 
[[ウェブサービス]]などで、[[クライアント]]と[[サーバー]]の[[時計]]がずれていて、
投稿時刻が「1分後」のように表示されちゃう、という変なやつをたまに見かけます。
そんなの多くないだろ!と思いそうですけど、意外とよく見ます。
[TIME[2024-01-21T11:26:51.200Z]]

[31] 
そういう場合10中8,9は[[クライアント]]の[[時計]]が狂ってるんですけど、稀に[[サーバー]]の[[時計]]が全然狂ってるじゃん、ってこともあります。
普通は[[サーバー]]の[[時計]]こそ狂わない (ちゃんとした技術者がちゃんと設定してるので。)
ものなんですけどね。偶発的なトラブルではなく偶発的にサーバーの時計が狂っているとしたら、
それはサービスの品質がなにかの犠牲になっている、ということです。
そういうのがこういう細かいところに表れてくるんですね。

[32] 
投稿時刻が[[未来][未来の日時]]になることなんてありえないから、
「後」になるものは全部一律で「たった今」みたいな表示にしちゃえばこの問題は解消するのでしょうけど、
大抵は
「投稿時刻」
専用ではなく汎用の日時表示処理を通しているから、あり得ない「後」の表示がちゃんと用意されちゃってるんですよね。

[33] 
まあ[[未来][未来の日時]]がありえない [[ambtime]] の用途が相当大部分を占めてそうなので、
それ専用の処理を用意しておいても損はないかなあという気もしますけど。

[34] 
ただ、たいてい過去だけどたまに未来、というケースに不具合を生んじゃう温床になりそうなのと、
[[クライアント]]の[[時計]]が狂っているというそもそも異常な場合にしか発生しないものなので、
そのためにわざわざ対策するのもちょっとなあ、という気持ちもありますね。

[35] [CITE@ja[XユーザーのM4y4さん: 「mixiのつぶやきが、543年前って表示されてるから、アセった!タイ暦になっていたからでした!」 / X]], [TIME[午後1:22 · 2011年5月1日][2011-05-01T04:22:37.000Z]], [TIME[2024-08-21T05:18:45.000Z]] <https://x.com/mayang_island/status/64545232078897152>

[36] 
>>35 どういう実装だとこうなるんだろう。
ロケール依存の現在年とサーバーが返した西暦年を計算してる感じ?

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Errors

Page name(s)