202011 のの会@関数Talk 26th | Talks around @Functions in Notes and Domino

@ -notes knows community- 2020/11/12 @関数Talk 第26回 公開版 @ 阿部 覚 (tw:) @abesat

@ 当初そういうつもりだったわけではありませんが 今回は、だいぶ以前…「第3回」の、 つづきと云えるかもしれません @

@ @TextToTime で放談 @

@ エピソード 私が扱っていた とある業務アプリケーションのデータベースに こんな感じのビューがありました ▶平成30 ▶平成30 ▶平成29 ▶平成27 ▶平成25 年10月16日 年09月23日 年04月07日 年08月27日 年07月24日 日付が和暦で並んでいるビュー というわけではなさそうで @

@ エピソード 和暦の日付は先頭のほうだけで 途中からこんな表示に ▶平成16 年03月03日 ▶平成15 年09月28日 ▶2018/03/12 ▶2017/08/05 ▶2017/05/31 ▶2017/02/06 ▶2016/11/17 ▶2016/11/04 @ まあ、むしろこちらの表記のほうが一般的ですね さらに…

@ エピソード ずっと下のほうへスクロールすると こんな表示も出てまいりました… ▶2002/07/30 ▶2002/03/06 ▶12/23/2017 ▶12/02/2016 ▶11/25/2015 ▶10/11/2018 ▶09/13/2017 ▶09/09/2016 @ つまり形式が混在しているために 日付順のビューとしては機能していない、 ちゃんと並んでいない現状

@ エピソード ビューの設計上は、この列は とある承認日フィールドを表示しているだけ フォームを見ると その承認日フィールドはただのテキストで @ 承認ボタンを押したときのアクションが このフィールドに今日の日付をテキストに変更して セットしていました

@ エピソード 問題は、承認する人の一部に、 OSの日時データ形式を 和暦にしちゃっている人がいたこと、 @

@ エピソード あるいは外国人社員さんで OSの日時設定を変更…多くは英語形式に 変更されている方がいたことなどでした @

@ エピソード 結果として、そうした方たちが承認した文書では 承認日付のフィールドに 和暦や、"月/日/年"の表記が 設定されてしまっていた、という次第です @

@ エピソード 私がその業務に入るより以前から 長年放置されていたビューで 利用者もさほどいなかったこともあり、 ずっと静観していましたが あるときふと思い立ち OSの影響とはいえ、 日付をセットしているのは、 そもそもNotesの式やスクリプトだよな だったら… @

@ エピソード ビューの列式をこう変えました @

@ エピソード 直りました ▶2018/10/16 ▶2018/10/11 ▶2018/09/23 ▶2018/03/12 ▶2017/12/23 ▶2017/04/07 ▶2017/08/05 ▶2017/05/31 ▶2017/04/07 @

@ 「第3回」のTalkでは、 @Textを使って日時を文字形式に変換する場合の 課題について触れました @Text関数だけでなく、LotusScriptでのText変換でもおなじ ようなことがいえますが いずれ、利用者それぞれの環境・設定の違いによって 前述のビューのような表示の違いが起きえます @ でも、そんな違いを @TextToTimeで、ある程度は是正できるようです

• https://www.slideshare.net/abesat/201806-talk-3rd

改めて @TextToTime について @ 構文は単純で、引数は文字列だけです @TextToTime( string ) ヘルプでは 「文字列を日時値に変換できる場合は、変換します。」 とありますが @ どこまで変換可能かは明示されていないので

改めて @TextToTime について @ "/" と数字を組み合わせて日付を取得する 👈Excelなどと同様に、年を指定しなければ今年 ":" と数字を組み合わせて時間を取得する あるいはその両方で日時を取得する @ というのが、一般的な使い方だと思います

@ 追加検証 日付に関しては、 「海外での日付の並び順もある程度サポートするらしい」 「和暦の文字列も判別してくれるらしい」 というのを前述のエピソードで認識したわけですが 私の端末で改めてやってみたところ @ 「海外での日付の並び順」については、まあ予想通り

@ 追加検証 しかし、和暦については… あれ？ 平成30年が2030年？ @

@ 追加検証 すぐ原因に気づきました 私のNotesは英語版で、そもそも和暦が入っていないなと @ だから昭和も平成も、もちろん令和も認識しない でも、エラーにもならないわけだ

@ 追加検証 そこで、さらに試してみました @ 元号は認識しないけど、時間表現は認識 これはOS側から情報得られるのかな （Notesは英語版だけどWindowsは日本語版なので…？）

@ 追加検証 @ 全く日時として認識できない文字列でも… 間の数字だけを使って勝手に年月日になった！

@ 追加検証 文字列内の数字の箇所が増えると日付というより日時に もちろん日時として適切な数値の範囲内なら、でしょうけど @ 以上、例によって、ここまでの検証には 実用性はあまりありませんが この関数の性格も、ほの見えたということで✋

@ 今回もお付き合い ありがとうございました 😀 @