#?SuikaWiki/0.9
[1] [[IMAP]] で使われる日付形式は、同じ[[電子メイル]]関係で使われる形式である
[[RFC2822の日付形式]]にもやや似ていますが、
微妙に異なり、互換性はありません。

[REFS[
- [5] 
[CITE@en[RFC 3501 - INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1]] ([TIME[2018-02-01 03:51:41 +09:00]]) <https://tools.ietf.org/html/rfc3501#page-85>
- [6] [CITE@en[RFC 2060 - Internet Message Access Protocol - Version 4rev1]] ([TIME[2018-01-28 19:02:32 +09:00]]) <https://tools.ietf.org/html/rfc2060#page-68>
]REFS]

[2] RFC 3501 ABNF 抜粋 : 
-date            = date-text / DQUOTE date-text DQUOTE
-date-day        = 1*2DIGIT ; Day of month
-date-day-fixed  = (SP DIGIT) / 2DIGIT ; Fixed-format version of date-day
-date-month      = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
-date-text       = date-day "-" date-month "-" date-year
-date-year       = 4DIGIT
-date-time       = DQUOTE date-day-fixed "-" date-month "-" date-year SP time SP zone DQUOTE
-time            = 2DIGIT ":" 2DIGIT ":" 2DIGIT ; Hours minutes seconds
-zone            = ("+" / "-") 4DIGIT
[PRE[
          ; Signed four-digit value of hhmm representing
          ; hours and minutes east of Greenwich (that is,
          ; the amount that the given time differs from
          ; Universal Time).  Subtracting the timezone
          ; from the given time will give the UT form.
          ; The Universal Time zone is "+0000".
]PRE]

[4] 
[CODE(ABNF)[date-text]] は必ずしも固定長ではなく、
[CODE(ABNF)[date-time]] は必ず固定長になります。
どちらの定義が使われるかは場面によります。

[3] 例 : 
- [SAMP(IMAP)[17-Jul-1996 02:44:25 -0700]]


[12] [[時間帯]]については[[インターネットメールの時間帯表記]]も参照。

[FIG(quote)[
[FIGCAPTION[
[7] [CITE@en[RFC 1064 - Interactive Mail Access Protocol: Version 2]]
([TIME[2018-02-04 11:06:30 +09:00]])
<https://tools.ietf.org/html/rfc1064#page-24>
]FIGCAPTION]

>    date            ::= string in form "dd-mmm-yy hh:mm:ss-zzz"

]FIG]


[FIG(quote)[
[FIGCAPTION[
[8] [CITE@en[RFC 1176 - Interactive Mail Access Protocol: Version 2]]
([TIME[2018-01-21 21:01:02 +09:00]])
<https://tools.ietf.org/html/rfc1176#page-26>
]FIGCAPTION]

>    date            ::= string in form "dd-mmm-yy hh:mm:ss-zzz"

]FIG]


[FIG(quote)[
[FIGCAPTION[
[9] [CITE@en[RFC 1176 - Interactive Mail Access Protocol: Version 2]]
([TIME[2018-01-21 21:01:02 +09:00]])
<https://tools.ietf.org/html/rfc1176#page-22>
]FIGCAPTION]

> InternalDate " 9-Jun-88 12:55:44 PDT"

]FIG]


[FIG(quote)[
[FIGCAPTION[
[10] [CITE@en[RFC 1203 - Interactive Mail Access Protocol: Version 3]]
([TIME[2018-01-23 00:10:54 +09:00]])
<https://tools.ietf.org/html/rfc1203#page-38>
]FIGCAPTION]

> date            ::= string in form "dd-mmm-yy hh:mm:ss-zzz"
> 

]FIG]


[FIG(quote)[
[FIGCAPTION[
[11] ([TIME[1992-12-12 09:00:00 +09:00]])
<https://www.mirrorservice.org/sites/ftp.cac.washington.edu/mail/old/IMAP2bis.TXT>
]FIGCAPTION]

>    date            ::= date_new / date_old
>    date_new        ::= string in form "dd-mmm-yyyy hh:mm:ss -zzzz"
>    date_old        ::= string in form "dd-mmm-yy hh:mm:ss-zzz"
>    In date_new, the year is now a 4-digit year, and the timezone is a
>    signed four-digit value of hhmm representing hours and minutes west
>    of Greenwich (that is, the amount that the given time differs from
>    Universal Time).  Subtracting the timezone from the given time will
>    give the UT form.
>    Universal Time is expressed as "+0000".
>    date_old is hereby declared obsolete, and its usage in new software
>    is STRONGLY discouraged.  However, client implementations MUST
>    recognize and properly parse it.
>    RFC-1176 documents the argument to the SEARCH criteria BEFORE, ON, and
>    SINCE as being either "date" in the text and "string" in the BNF.
>    These SEARCH criteria arguments are hereby amended to be "day", with
>    the following syntax:
>    day             ::= day_new / day_old
>    day_new         ::= string in form "dd-mmm-yyyy"
>    day_old         ::= string in form "dd-mmm-yy"
>    day_old is hereby declared obsolete, and its usage in new software
>    is STRONGLY discouraged.  However, server implementations MUST
>    recognize and properly parse it.

]FIG]
