UTCにしてしまっているところを全部JSTにした

[Pugma]

close #70
DB的には

• UTC管理で表示だけ直す
• そもそもJSTだけで値をいれる

だとどちらのほうがいいんでしたっけ？

[mehm8128]

DBの話は分からんのでこっちでも一応召喚 @ras0q

[ras0q]

バックエンドもまだ対応しきれてないのでなんとも言えないんですが文字列連結じゃなくてDateにパースしてJSTを設定するとかがいいかもです
traPtitech/traPortfolio#148

[motoki317]

細かいかもですが、必ずしもユーザーのコンピュータがJSTを利用しているとは限らないので、その場合はまずいかも？

今更かもですが、通信上やDB上の表現は時刻の文字列でなく、全部unix timestamp (seconds)の数字にしたほうがややこしい事が少なくなるかもしれません
JSだけtoDate()やnew Date(number)が標準的なsecondsではなくmillisecondsになるのでアレなんですが、そこだけ気をつければ
気をつければどちらでも良いかとなったので好きな方で

[Pugma]

MDN: https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Date
を見てみたところ、直接jsのdate型にparseするのはよくなさそう？って感じです
確か、mariadbとかもdatetime型はstringのformat指定版みたいな扱いだった記憶があるので、文字列でAPIに流し込んでもいいんじゃないかなという気がしています…

Date.parse()
日付を表す文字列を解釈して、地方時で 1970 年 1 月 1 日 00:00:00 から経過したミリ秒数を表す数値を返します。うるう秒は無視します。

メモ: ブラウザーごとに動作が異なり一貫性がないため、 Date.parse で文字列を解釈しないことを強く推奨します。

[mehm8128]

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Date/parse

対応するよう明示的に指定されているのは ISO 8601 形式 (YYYY-MM-DDTHH:mm:ss.sssZ) のみです。

って書いてあるので、この形式でやるなら大丈夫そうです

[ras0q]

フロントエンドではブラウザのTZに従って時刻を表示して、APIに渡すときはUTC(Date.toISOString())で渡してもらうのがよさそうです？

new Date()
Mon May 27 2024 12:08:09 GMT+0900 (日本標準時)

new Date().toISOString()
'2024-05-27T03:08:11.325Z'

new Date('2024-05-27T03:08:11.325Z')
Mon May 27 2024 12:08:11 GMT+0900 (日本標準時)

https://zenn.dev/yoonchulkoh/articles/cb88d9a25aec8d