Notes/Dominoの@関数を取り上げながら、調べたこと、経験したことを雑談してゆきます。 第26回は @TextToTime について。

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

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

3. @
@
@TextToTime
で放談

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

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

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

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

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

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

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

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

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

13. @
@
エピソード
▶
▶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
直りました

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

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

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

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

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

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

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

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

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

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