WEBVTT

1
00:00:00.000 --> 00:00:01.058
こんにちは。

2
00:00:01.058 --> 00:00:06.082
今回はジャバスクリプトのデート・プロトタイプ・トゥーアイエスオー文字列、

3
00:00:06.082 --> 00:00:11.107
トゥーアイエスオーストリングを紹介します。

4
00:00:11.107 --> 00:00:19.745
これは、デートオブジェクトが持つ日時を、世界共通のアイエスオー形式の文字列へ変換するメソッドです。

5
00:00:19.745 --> 00:00:26.797
結果はユーティーシー、つまり協定世界時を基準に表され、末尾にはゼットが付きます。

6
00:00:26.797 --> 00:00:35.612
地域によって表示が変わらないため、サーバーとブラウザーの間で時刻を受け渡す場面にとても向いています。

7
00:00:35.612 --> 00:00:40.372
この動画では、引数と戻り値、基本例、日付がずれる理由、そしてエラーになる条件まで、

8
00:00:40.372 --> 00:00:45.132
実行結果と一緒に学びます。

9
00:00:45.132 --> 00:00:54.652
日時を扱う処理は、見た目と中身がずれやすい分野なので、変換のルールを最初に理解しておくことがとても大切です。

10
00:00:54.652 --> 00:00:56.483
まず動作環境を確認します。

11
00:00:56.483 --> 00:01:01.623
このメソッドは古くからある機能で、クロームではバージョン三以降、ファイアーフォックスでは一以降、

12
00:01:01.623 --> 00:01:06.764
サファリでは四以降、エッジでは十二以降で使えます。

13
00:01:06.764 --> 00:01:11.270
ノード・ジェイエスでも、ゼロ・一ゼロ・ゼロ以降で対応しています。

14
00:01:11.270 --> 00:01:19.016
記事の互換性情報は、エムディーエヌのデータに基づく目安で、すべての環境で実機検証したという意味ではありません。

15
00:01:19.016 --> 00:01:25.213
追加のパッケージやインポートは必要なく、デートオブジェクトを作ればそのまま呼び出せます。

16
00:01:25.213 --> 00:01:30.846
ブラウザーのコンソールでも、ノードでファイルを実行しても、同じコードで試せます。

17
00:01:30.846 --> 00:01:37.184
長く安定して使えるメソッドなので、古いブラウザーを対象に含む案件でも安心して採用できます。

18
00:01:37.184 --> 00:01:39.161
引数と戻り値を確認します。

19
00:01:39.161 --> 00:01:46.613
書き方は、デートオブジェクトのあとにドットを書き、トゥーアイエスオーストリングとカッコを続けます。

20
00:01:46.613 --> 00:01:52.544
リファレンス名にあるプロトタイプは、実際の呼び出しで毎回書く必要はありません。

21
00:01:52.544 --> 00:01:53.913
引数はありません。

22
00:01:53.913 --> 00:02:00.757
カッコの中に何か渡すのではなく、有効なデートオブジェクトに対して呼び出す点がポイントです。

23
00:02:00.757 --> 00:02:05.015
戻り値は、ゼット付きの日時文字列で、タイプは文字列です。

24
00:02:05.015 --> 00:02:08.361
元のデートオブジェクト自体は変更されません。

25
00:02:08.361 --> 00:02:14.292
呼び出す対象と、引数がないこと、この二つを押さえれば使い方はほぼ理解できます。

26
00:02:14.292 --> 00:02:17.579
返ってくる文字列の形を読み解きます。

27
00:02:17.579 --> 00:02:26.162
通常は、年、月、日をハイフンでつなぎ、文字のティーを挟んで、時、分、秒をコロンでつなぐ形です。

28
00:02:26.162 --> 00:02:32.006
秒の後ろには小数点と三桁のミリ秒が続き、最後にゼットが付きます。

29
00:02:32.006 --> 00:02:37.302
このゼットが、ユーティーシーで表した時刻だという合図です。

30
00:02:37.302 --> 00:02:46.432
桁数がそろった決まった形なので、文字列のまま並べ替えたり、辞書順で比較したりしやすい利点もあります。

31
00:02:46.432 --> 00:02:50.450
逆に、人間向けの見やすい表示ではありません。

32
00:02:50.450 --> 00:02:58.302
保存や通信にはこの形、画面表示には地域に合わせた別の形、と役割を分けて考えてください。

33
00:02:58.302 --> 00:03:06.520
一度この読み方を覚えれば、ログや通信データに残った日時も、迷わず読み解けるようになります。

34
00:03:06.520 --> 00:03:08.184
記事の基本例を見ます。

35
00:03:08.184 --> 00:03:13.023
入力は、二千二十六年九月二十一日、午前九時、日本時間の日時です。

36
00:03:13.023 --> 00:03:19.375
プラスゼロ九ゼロゼロは、日本時間がユーティーシーより九時間進んでいることを示します。

37
00:03:19.375 --> 00:03:24.970
変換すると九時間が引かれ、同じ日の午前零時、ユーティーシー表記になります。

38
00:03:24.970 --> 00:03:29.507
これが記事の期待出力で、ノードの実機結果とも一致しています。

39
00:03:29.507 --> 00:03:35.859
ファイルに保存してノードで実行しても、ブラウザーのコンソールに貼っても同じ結果です。

40
00:03:35.859 --> 00:03:42.362
再宣言エラーが出たら、ページを再読み込みするか、コード全体をブロックで囲んでください。

41
00:03:42.362 --> 00:03:48.260
実行前に、九時間を引くと何時になるかを予測してから、結果と比べてみてください。

42
00:03:48.260 --> 00:03:50.981
期待出力をもう一例で深掘りします。

43
00:03:50.981 --> 00:03:54.982
日本時間の一月一日、午前零時三十分を変換すると、結果は前年の十二月三十一日、

44
00:03:54.982 --> 00:03:58.983
十五時三十分になります。

45
00:03:58.983 --> 00:04:04.265
日付が前日にずれているように見えますが、これはバグではありません。

46
00:04:04.265 --> 00:04:07.466
九時間の時差を引いた正しい変換結果です。

47
00:04:07.466 --> 00:04:16.749
記事でも、日本時間の表示文字列ではなくユーティーシーへ変換されるので、日付が前日になることもあると注意されています。

48
00:04:16.749 --> 00:04:22.510
ログの日付が一日ずれて見えたら、まずユーティーシー変換を疑ってください。

49
00:04:22.510 --> 00:04:27.792
表示のずれと、時刻そのものの間違いは、分けて考えることが大切です。

50
00:04:27.792 --> 00:04:33.249
実用例として、送信データ向けに日時を整える関数を作ります。

51
00:04:33.249 --> 00:04:35.320
処理の順番が大切です。

52
00:04:35.320 --> 00:04:43.412
まず、入力からデートオブジェクトを作り、ゲットタイムで有効な時刻かどうかを確認します。

53
00:04:43.412 --> 00:04:52.068
ナン、つまり数値でない結果なら、変換を試みずに、理由が伝わるエヌジーのメッセージを返します。

54
00:04:52.068 --> 00:04:58.467
有効な場合だけ、トゥーアイエスオーストリングを呼んで結果を返します。

55
00:04:58.467 --> 00:05:04.112
変換メソッド単体では、無効な日付で例外が発生してしまいます。

56
00:05:04.112 --> 00:05:12.769
前段のチェックを組み合わせることで、利用者に理由が伝わり、処理が途中で止まることも防げます。

57
00:05:12.769 --> 00:05:19.732
段階を分けておくと、後から仕様が変わっても、直す場所がすぐに見つかります。

58
00:05:19.732 --> 00:05:22.122
実用例の実行結果を確認します。

59
00:05:22.122 --> 00:05:28.497
日本時間の正しい日時を渡すと、ユーティーシーのアイエスオー文字列に変換されます。

60
00:05:28.497 --> 00:05:35.190
日付として読めない文字列を渡した場合は、例外ではなくエヌジーのメッセージが返ります。

61
00:05:35.190 --> 00:05:37.581
この出力も実機で確認済みです。

62
00:05:37.581 --> 00:05:44.593
こうして整えた文字列は、ジェイソンに載せてサーバーへ送るデータとしてもそのまま使えます。

63
00:05:44.593 --> 00:05:50.171
受け取る側も、決まった形だと分かっているので、安心して日時に戻せます。

64
00:05:50.171 --> 00:05:56.864
チェックと変換を一つの関数にまとめておくと、画面が増えても同じ品質で日時を扱えます。

65
00:05:56.864 --> 00:05:58.405
最も大切な注意点です。

66
00:05:58.405 --> 00:06:02.889
ナンから作ったデートなど、無効なデートに対してこのメソッドを呼ぶと、文字列が返るのではなく、

67
00:06:02.889 --> 00:06:07.373
レンジエラーという例外が発生します。

68
00:06:07.373 --> 00:06:14.660
これは記事の境界条件の例でも示されている動きで、実機でもエラー名がレンジエラーになることを確認済みです。

69
00:06:14.660 --> 00:06:21.385
利用者の入力や、外部から受け取った文字列からデートを作る場合は、そのまま呼ばずに注意が必要です。

70
00:06:21.385 --> 00:06:28.812
トライとキャッチで囲むか、前の実用例のように事前に有効性を確認するか、どちらかの備えを必ず入れてください。

71
00:06:28.812 --> 00:06:31.669
もう一つ、混同しやすい点があります。

72
00:06:31.669 --> 00:06:39.288
このメソッドの結果は常にユーティーシー表記で、日本の利用者が普段見る時刻の見た目にはなりません。

73
00:06:39.288 --> 00:06:46.590
午前九時のつもりで保存したのに、表示が午前零時になっていた、という混乱はここから生まれます。

74
00:06:46.590 --> 00:06:52.304
利用者向けの表示には、地域に合わせた整形を行う別の方法を使ってください。

75
00:06:52.304 --> 00:06:54.209
役割分担はシンプルです。

76
00:06:54.209 --> 00:06:59.288
保存と通信にはアイエスオー形式、画面表示には地域向けの形式です。

77
00:06:59.288 --> 00:07:06.748
どちらの目的で文字列を作っているのかを先に決めることが、時刻まわりのバグを防ぐ一番の近道です。

78
00:07:06.748 --> 00:07:12.304
特に、保存した文字列をそのまま画面に出す設計は、見直しの優先候補です。

79
00:07:12.304 --> 00:07:13.104
まとめです。

80
00:07:13.104 --> 00:07:21.901
トゥーアイエスオーストリングは、デートオブジェクトの日時を、ユーティーシーのアイエスオー形式文字列へ変換するシンプルなメソッドです。

81
00:07:21.901 --> 00:07:23.501
導入時の判断は三つです。

82
00:07:23.501 --> 00:07:27.633
まず、引数はなく、戻り値はゼット付きの文字列だと押さえること。

83
00:07:27.633 --> 00:07:33.365
次に、無効なデートではレンジエラーになるため、事前確認やトライとキャッチで備えること。

84
00:07:33.365 --> 00:07:37.630
そして、保存や通信に使い、地域向けの表示とは使い分けることです。

85
00:07:37.630 --> 00:07:43.228
投稿時刻の保存や、サーバーへの送信データ作りなど、身近な場面から試してみてください。

86
00:07:43.228 --> 00:07:44.428
お疲れさまでした。

87
00:07:44.428 --> 00:07:49.493
基本例の日付を変え、日付がどうずれるか予測するところから始めてみてください。

88
00:07:49.493 --> 00:07:53.492
慣れてきたら、自分の画面の保存処理へ組み込んでみてください。