あずさにゃん
Device Simulation、Firefox 50くらいのときには既にありませんでしたか……？（本当に追加されたのはそれより更に前だと思われる）
Firefox 15から存在していたっぽい https://en.wikipedia.org/wiki/Firefox_version_history#Firefox_10_through_16
哲学、基本的に生の意味を考える学問でありながら、デカルトに始まる「自分の観測が絶対的な真実」というドグマにも支配されているので、生と表裏一体の死を見たことがないのはフェイク野郎であるみたいな感覚が多かれ少なかれありそう
やっぱり死の向こうに何があるか見とくと色々な議論が楽になりそうだから見てみたくなるよね
哲学はill-definedな問題を考え続けるから精神がヤバくなるけど、数学ならwell-definedだから安心安全ですよ（個人の感想です）
JavaScriptのDateってタイムゾーン情報入ってるんだっけ？getTimezoneOffsetとかもフィールドじゃなくてブラウザのロケールを見に行くと思ってたけど
Temporal API普通にJavaのDateTimeと同じノリで使えたけど
あーstrftimeがなくて代わりにISO-8601形式のどのコンポーネントを出力するかの制御になってるのか https://tc39.es/proposal-temporal/docs/zoneddatetime.html#toString
一回だけtoISODateTimeString()みたいな関数作ればそれで終わりじゃない？
Temporal APIのMachine-readable FormatとHuman-readable Formatの区分はかなり正しいことを言ってるけど、人間がアホなため大抵の場所はいまだに二者の区別がゆるふわなのでTemporal APIがstrictなことを言い始めると小回りが効かなく見えるという問題っぽく感じる https://tc39.es/proposal-temporal/docs/strings.html#machine-readable-vs-human-readable-string-formats
Human-readable formatをロケールに全部押し付けてんのはあんまり良くないかな（どうせ機械非可読でいいならもっと自由にフォーマットしたいというのはある）
さすがにDBが日付型のデータを返してくる時ってISO-8601で返してくれないの……？この辺いつもbindingに任せてるから分からん
このアカウントは、notestockで公開設定になっていません。
なるほどTemporal APIのparsingはオフセットだけじゃなくてZone IDも明示的に要求するのか……（サマータイムはカス事案） https://tc39.es/proposal-temporal/docs/strings.html#why-is-a-bracketed-time-zone-annotation-required-to-parse-a-string-into-a-temporalzoneddatetime-object
DB保存時にタイムゾーン落ちてるなら逆に議論の余地なく常にタイムゾーン情報の修復しないといけないから相対的に楽なのでは？（ぐるぐる目）
MySQL（やPostgreSQL？）のdateやtimeは(yyyy, mm, dd, HH, MM, SS)をベタに保存するからヤバいって時代で知識が止まってるんだけど、最近のDBで日付型ってどうなってるの
DBのデータとしてタイムゾーンが問題になることはほとんどないので、何も考えずInstantを保存するようになってから永劫の時が過ぎた
nordotって共同通信のドメインじゃなくて情報仲介屋のサービスなんだ（あんまり良い印象なかった）
このアカウントは、notestockで公開設定になっていません。
