So-net無料ブログ作成

時間の種類の抽出 [iCalendar]

とりあえず、どっから行けばいいかなぁと考えて、型から見て行くことにしました。DATEDATE-TIMEDURATIONPERIODTIMEUTC-OFFSET辺りが該当しますでしょうか・・。

ちなみに以前、型について見たのはこちらです。この回の内容を見ていると、DATE-TIME型の表記方法で全てが見れる様な気がします。以下の3つが定義されていますね。

  • ローカル時刻
  • UTC時刻
  • タイムゾーン指定のローカル時刻


それぞれについて見て行こうかと思いますが、その前に一点、DATE-TIME値にUTCオフセットは使用するなとのこと(MUST NOT)。

それでは、見て行きます。

【ローカル時刻】
表記は単純に「19980118T230000」で1998年1月18日午後11時を示します。で、このタイプのものは「Floating time」と呼ばれ、いずれのタイムゾーンにも紐付けられないとのことです。と言うことで、どのタイムゾーンに入ってもこの表記で書かれた時間は変わらないとのこと。例えば、ローカル時刻で毎日11:00AM~1:00PMと定義されているイベントはその人が日本にいようが、アメリカにいようがどこにいようと毎日11:00AM~1:00PMのイベントになるとのこと。下記の縛りがあります。

  • ローカル時刻で記載されたiCalendarオブジェクトを受けた場合は、相手がいずれのタイムゾーンにいたとしても、その時刻で解釈するべき(SHOULD)。
  • 「Floating time」はそれを使用するのが妥当な場合のみ使用されるべき(SHOULD)。
  • 固定的な時間でやり取りする際は、UTC時刻かタイムゾーン付きのローカル時刻でやり取りしなければならない(MUST)。


「VTIMEZONE」カレンダーコンポーネントがiCalendarオブジェクト内にない限り「Floating time」として扱うこととのことです。


【UTC時刻】
そもそも「UTC」って何と思って調べたところ、Universal Time, Coordinatedの略で、「協定世界時」だそうです。

表記はローカル時刻のフォーマットの末尾に「Z」を付加するとのこと。「19980119T070000Z」でUTC時刻の1998年1月19日の午前7時となるようです。時刻表記はたぶん24時間表記ですね。と思って、一応3.3.12 Timeの節を確認したところ、時間は「0-23」で表記する様です。

で、UTC時刻を使う場合は「TZID」プロパティパラメータ(タイムゾーンの指定)は付加してはならない(MUST NOT)とのことです。


【タイムゾーン指定のローカル時刻】
TZID」プロパティパラメータを使用して、タイムゾーンを指定した形で日時を表記するものです。「TZID=America/New_York:19980119T020000」で、ニューヨークでの1998年1月19日午前2時を表します。

この表記の場合、サマータイム(daylight time)から標準時刻(standard time)への変更時に同じ時刻が一回以上(2回?)発生する場合がありますが、DATE-TIME値は最初に発生する時点を指すとのことです。逆に標準時刻(standard time)からサマータイム(daylight time)への変更時には指定した時刻が1度も発生しない可能性があります。この場合は、ローカル時刻でギャップが生じる前にUTCオフセットを用いて解釈しますとのこと。

また、うるう秒は時刻表記内の秒の箇所に「60」で表記しなければならい(MUST)。うるう秒をサポートしていない実装は「60」秒を「59」秒として扱うべき(SHOULD)。


以上が、DATE-TIME型について記載されていた内容です。TIME型にも同じ様な説明がありそうだったので、また見とこうと思います。後、「TZID」プロパティがテキストでの記載となっています。このあたり、どういう値が定義されているのか見ときたいですね。

と言うことで、次回は「TZID」を見ようと思います。




ARROWS

時間について [iCalendar]

長々と続けてRFC5545を一通りなめたことになっていますが、あちこちで「後で見る」としていた時間関係の話が残っています。普通にローカルタイムベースで考えると話は単純なのですが、昔、Zaurus向けにスケジューラアプリを作成した際、Zaurusの中でも複数の時間表記があって、整合性を取るのに苦労した気がします・・。と言うことで、ちゃんと押さえたいと思った次第であります・・。

*

さて、どう進めましょうか・・。まずは、目次から時間に関係のありそうな項目を書き連ねて行きましょうか。



とまあ、羅列するとこんな感じでしょうか・・。抜けがあるかもしれませんが、このあたりを足がかりに時間関係の仕様を追っていくことにします。





RFC2445との差分 [iCalendar]

ざ~っと見るのも最後になりますが、Appendix Aで、RFC2445との差分です。本ブログでは、RFC5545を見て行きましたが、まだ、メジャーなのはRFC2445なんですかね?その辺よく把握してません・・。まあ、とりあえず差分を見て行きましょう。


まず最初は新規に発生した制限事項から。

  1. 「DTSTART」プロパティは繰り返しのルールが記述されていれば、そのルールに合致しているべき(SHOULD)
  2. 「RRULE」プロパティは一つのコンポーネントに複数は記述しないべき(SHOULD NOT)。
  3. 「BYHOUR」「BYMINUTE」「BYSECONDE」ルールは「DTSTART」プロパティが「DATE」値で記載されている時は「RRULE」プロパティに記載してはいけない(MUST NOT)。
  4. 「DTEND」もしくは「DUE」プロパティは「DTSTART」プロパティの型と一致しなければならない(MUST)。
  5. 「DURATION」プロパティは「VFREEBUSY」コンポーネントに記載されなくてもよい(制限事項??)
  6. MIMEの通信に置いて、「charset」コンテントタイプパラメータの使用は必須。


続いては、削除された制限事項について。

  1. 「DTSTART」「DTEND」プロパティは繰り返し規則に使われた場合、ローカルタイムとタイムゾーンを記載する必要はない。


奨励されない点は下記の通り。

  1. 「EXRULE」プロパティはコンポーネント内に記載されなくてもよい。
  2. 「THISANDPRIOR」値は「RANGE」パラメータに使用されなくてもよい。
  3. 「PROCEDURE」値は「ACTION」プロパティに使用されなくてもよい。
  4. 「RECUR」型はCOMMAで区切られた値のリストによる複数の値を許容しない。
  5. 「x-name」部分は、「RECUR」型のプロパティの記載に使用されない。代わりに「x-param」は記載可能。


以上、やっと一通りなめ終わりました~っ! どんだけかかっとんやと言う感じですが、まだ終わってません・・・。次回からは後回しにしていた、日付、時間関係の話題でも・・・。






IANAに登録されているコンポーネント - IANAについて [iCalendar]

8.2はIANAへの新規要素の登録に関する手続きが書かれている様ですが、とりあえず、仕様の把握には関係なさげなので飛ばします。

で、コンポーネントについて。次のものが登録されている様です。

VCALENDARRFC 5545 Section 3.4
VEVENTRFC 5545 Section 3.6.1
VTODORFC 5545 Section 3.6.2
VJORNALRFC 5545 Section 3.6.3
VFREEBUSYRFC 5545 Section 3.6.4
VTIMEZONERFC 5545 Section 3.6.5
VALARMRFC 5545 Section 3.6.5
STANDARDRFC 5545 Section 3.6.5
DAYLIGHTRFC 5545 Section 3.6.5


・・・と言うのを続けようかと思いましたが、RFCを見ればわかるので、あまり意味がありませんね・・・。

次回はAppendixでも見て行くことにします。








ブログを作る(無料) powered by So-netブログ

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。

×

この広告は1年以上新しい記事の更新がないブログに表示されております。