Bug(バグ) #2119
完了#1706 の対応をしないため、機能についての説明を追記する
0%
説明
#1706 の対応をするには、根本的に仕様の見直しが必要となります。
安定版3.4での対応が難しいため、機能についての動作説明を管理画面に追記します。
説明文の案として、下記に例を示します。
「ProfileForm で日付型のプロフィール項目の最大値・最小値の入力欄に strtotime() が解釈できる文字列を入力すると、 プロフィール項目を保存した時点から計算した値が DB に保存されます。」
Minoru Takai さんが13年以上前に更新
#1706 が不具合なのか仕様なのかという点から疑問なのですが、いずれにせよ動作が曖昧な部分に対して、
「ProfileForm で日付型のプロフィール項目の最大値・最小値の入力欄に strtotime() が解釈できる文字列を入力すると、
プロフィール項目を保存した時点から計算した値が DB に保存されます。」
のような説明を追加することが好ましいと考える理由がよく分かりません。このような説明を追加してしまったら余計に混乱を招くように思います(「プロフィール項目を保存した時点から計算した値が DB に保存され」ることを仕様と認めるということを意味しますが、これは #1706 では不具合として扱っていますよね)。
この対応は不要(むしろ対応すべきではない)と考えていますが、 #1706 の問題が先送りになるからといって、このような文言を追加すべきだという根拠があればそれを示して頂きたいです。
Mutsumi Imamura さんが13年以上前に更新
2011/06/06現在、親チケット( #1706 )の記述を確認すると、
now や 2010-09-17 や next Sunday といった文字列をその時点での日付に変換した上で、メンバーの入力値と比較するのが正しい挙動である。
と明記されているので、今後想定している仕様と異なった挙動を説明する文言を追加するというのは好ましくないと思います。
よって、私もこの対応はしない方が良いと感じます。
捉え方次第かもしれませんが、現状の管理画面の説明文の入力例をみても
Please input in format: YYYY/MM/DD HH:MM:SS . For example: 2009/01/01 23:59:21
その他、 PHP の strtotime() 関数が解釈することのできる特殊な文字列が利用可能
となっており、YYYY/MM/DD HH:MM:SSといった形式で入力することを推奨しているように感じます。
なので、now等の文字列を入力した際の挙動についての説明の必要性をそこまで感じません。