アカウント名:
パスワード:
基本形式(YYYYMMDDThhmmss+0900)または拡張形式(YYYY-MM-DDThh:mm:ss+09:00)のどちらかに準拠して欲しい
関連リンク：米国と欧州の日付フォーマットの違いにより、児童ポルノ送信容疑をかけられたスペインの家族 | スラド IT [it.srad.jp]
機械処理するデータとしてなら賛成。人が読むための物だと、YYYYMMDDは視認性が悪く、YYYY-MM-DDは範囲を表す記号に悩む。
> 機械処理するデータとしてなら賛成。
機械処理するなら Unix Time 以外に選択肢ないでしょ……てか、Excel で日付表示になっていても、実データは Unix Time でしょ。
えぇっ？2038年って意外と近いと思うんですよ
その頃はとっくに現役引退してるし2000年問題のときも大きな問題なかったから大丈夫と無責任なことを言ってみる
2038年にならなくとも2038年を入力することはあるんだが・・・無責任以前に無能じゃないか。あと2000年問題は対応したから大きな問題にならなかったんだぞ。
いやいや、2000年問題の時は、対応していないところも（自分のいた会社も含めて）あったかと。大混乱はなかったけれど、過ぎてから「やべ、直してない」というのがちらほら。
既に64bitにして解消しているプロダクトも結構ありますけどね。
Excelの日時の内部表現はUnix Timeではありませんよ。1900年1月1日と1904年1月1日の2種類です。
Excel の1900と1904日付システムの相違点 [microsoft.com]
Joel On Software私訳 なぜMicrosoft Officeファイルフォーマットはこんなにもややこしいのか (そしてその対処法を幾つか) [hatelabo.jp]
Excelワークシートには、2種類ある。日付のエポックが1900/1/1のもの(これには、Lotus 1-2-3 との互換性のために故意に入れられた閏年に関するバグがあるが、ここでそれについて述べるのは退屈すぎる)、および、1904/1/1のものだ。Excelは両方をサポートしているが、それはExcelの最初のバージョンはMac版であり、それは単に簡単だったという理由でOSのエポックを使っていて、しかしWindows版のExcelは1-2-3のファイルをインポートできなくてはならず、そしてそれは1900/1/1をエポックとして採用していたからだ。
知らないことについてコメントするのが申し訳ないが、前者のリンクは日付をシリアル値にと書いてあります（日時は書いてない）
御参考:
Office Open XML の日付時刻の取扱い - Qiitahttps://qiita.com/shota243/items/340d804a1c51b7b39d1e [qiita.com]
ありがとう。
もうこの仕様辞めても良いと思いますけどね…そもそも123もCPUやメモリが今と比較してあまりに低い基盤上で動かす為の工夫でしょうし。
タイムゾーンを持てない形式は論外。
1970年以前のデータを扱ったことが無いんですね。
1970年なんてまだ50年前だからねぇ。誕生日いれたら速攻崩壊する日付型とかないわぁ
え、別にUnix Timeでも1970年以前は扱えるでしょ
1901 年 12 月頃までは表せますよ。–2,147,483,648 なので・・・
UNIX システムコール time は、「エラー時に-1を返す」仕様だったりします。-1と比較せず、「0でエラー」って実装も見かけますし、安易にtime_t を signed にするのはトラブルの元です。
既にtime_tの負の値を扱っているシステムがありますしtime()の問題であってtime_tの問題ではないですよね。
え、だからISO 8601という話ではないの？(統一はもう無理だと思うけど)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
日時はISO 8601で (スコア:2, 参考になる)
基本形式(YYYYMMDDThhmmss+0900)または拡張形式(YYYY-MM-DDThh:mm:ss+09:00)のどちらかに準拠して欲しい
関連リンク：米国と欧州の日付フォーマットの違いにより、児童ポルノ送信容疑をかけられたスペインの家族 | スラド IT [it.srad.jp]
Re:日時はISO 8601で (スコア:0)
機械処理するデータとしてなら賛成。
人が読むための物だと、YYYYMMDDは視認性が悪く、YYYY-MM-DDは範囲を表す記号に悩む。
Re:日時はISO 8601で (スコア:1)
> 機械処理するデータとしてなら賛成。
機械処理するなら Unix Time 以外に選択肢ないでしょ……
てか、Excel で日付表示になっていても、実データは Unix Time でしょ。
Re:日時はISO 8601で (スコア:3)
えぇっ？
2038年って意外と近いと思うんですよ
Re:日時はISO 8601で (スコア:2)
その頃はとっくに現役引退してるし
2000年問題のときも大きな問題なかったから大丈夫
と無責任なことを言ってみる
Re: (スコア:0)
2038年にならなくとも2038年を入力することはあるんだが・・・
無責任以前に無能じゃないか。
あと2000年問題は対応したから大きな問題にならなかったんだぞ。
Re: (スコア:0)
いやいや、2000年問題の時は、対応していないところも（自分のいた会社も含めて）あったかと。
大混乱はなかったけれど、過ぎてから「やべ、直してない」というのがちらほら。
Re: (スコア:0)
既に64bitにして解消しているプロダクトも結構ありますけどね。
Re:日時はISO 8601で (スコア:2, 興味深い)
Excelの日時の内部表現はUnix Timeではありませんよ。1900年1月1日と1904年1月1日の2種類です。
Excel の1900と1904日付システムの相違点 [microsoft.com]
Joel On Software私訳 なぜMicrosoft Officeファイルフォーマットはこんなにもややこしいのか (そしてその対処法を幾つか) [hatelabo.jp]
Re: (スコア:0)
知らないことについてコメントするのが申し訳ないが、
前者のリンクは日付をシリアル値にと書いてあります（日時は書いてない）
Re:日時はISO 8601で (スコア:2, 興味深い)
御参考:
Office Open XML の日付時刻の取扱い - Qiita
https://qiita.com/shota243/items/340d804a1c51b7b39d1e [qiita.com]
Re: (スコア:0)
ありがとう。
Re: (スコア:0)
もうこの仕様辞めても良いと思いますけどね…
そもそも123もCPUやメモリが今と比較してあまりに低い基盤上で動かす為の工夫でしょうし。
Re: (スコア:0)
タイムゾーンを持てない形式は論外。
Re: (スコア:0)
1970年以前のデータを扱ったことが無いんですね。
Re: (スコア:0)
1970年なんてまだ50年前だからねぇ。
誕生日いれたら速攻崩壊する日付型とかないわぁ
Re: (スコア:0)
え、別にUnix Timeでも1970年以前は扱えるでしょ
Re: (スコア:0)
1901 年 12 月頃までは表せますよ。
–2,147,483,648 なので・・・
Re:日時はISO 8601で (スコア:1)
UNIX システムコール time は、「エラー時に-1を返す」仕様だったりします。
-1と比較せず、「0でエラー」って実装も見かけますし、
安易にtime_t を signed にするのはトラブルの元です。
Re: (スコア:0)
既にtime_tの負の値を扱っているシステムがありますし
time()の問題であってtime_tの問題ではないですよね。
Re: (スコア:0)
え、だからISO 8601という話ではないの？
(統一はもう無理だと思うけど)