Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 27.1Mb
PDF (A4) - 27.2Mb
HTML Download (TGZ) - 7.2Mb
HTML Download (Zip) - 7.2Mb


MySQL 5.6 リファレンスマニュアル  /  ...  /  日付リテラルと時間リテラル

9.1.3 日付リテラルと時間リテラル

日付値と時間値は、値の正確型とほかの要因に応じて、引用符付きの文字列や数値など、複数の形式で表現できます。たとえば、MySQL が日付を予想するコンテキストでは、'2015-07-21''20150721'20150721 のいずれも日付と解釈します。

このセクションでは日付リテラルと時間リテラルの許容される形式について説明します。許可されている値の範囲など、時間データ型の詳細は、次のセクションを参照してください。

標準 SQL と ODBC の日付および時間リテラル  標準 SQL では、型キーワードおよび文字列を使用して、時間リテラルを指定できます。キーワードと文字列の間の空白はオプションです。

DATE 'str'
TIME 'str'
TIMESTAMP 'str'

MySQL は、これらの構造と、対応する ODBC 構文も認識します。

{ d 'str' }
{ t 'str' }
{ ts 'str' }

MySQL 5.6.4 より前では、MySQL は型キーワードを無視し、前述の各構造は、型が VARCHAR の文字列値 'str' を生成します。

5.6.4 以降、MySQL は型キーワードを使用し、これらの構造はそれぞれ、後続の小数秒部分が指定されている場合はこの部分を含む DATETIME、および DATETIME の値を生成します。DATETIME には、標準 SQL の TIMESTAMP 型により密接に対応する範囲があり、ここには 0001 から 9999 の年範囲が含まれるので、TIMESTAMP 構文は、MySQL で DATETIME 値を生成します。(MySQL の TIMESTAMP 年範囲は 1970 から 2038 です。)

日時コンテキストでの文字列リテラルと数値リテラル  MySQL は次の形式で DATE 値を認識します。

  • 'YYYY-MM-DD' または 'YY-MM-DD' 形式の文字列として。緩やかな構文が許可されます。どの句読点文字でも、日付部分間の区切り文字として使用できます。たとえば、'2012-12-31''2012/12/31''2012^12^31'、および '2012@12@31' は同等です。

  • 'YYYYMMDD' または 'YYMMDD' 形式の、区切り文字がない文字列 (日付として適切なもの) として。たとえば、'20070523''070523''2007-05-23' として解釈されますが、'071332' は正しくないため (月と日の部分が不適切)、'0000-00-00' になります。

  • YYYYMMDD または YYMMDD 形式の数値 (日付として適切なもの) として。たとえば、19830905830905'1983-09-05' として解釈されます。

MySQL は次の形式で DATETIME および TIMESTAMP 値を認識します。

  • 'YYYY-MM-DD HH:MM:SS' または 'YY-MM-DD HH:MM:SS' 形式の文字列として。緩やかな構文はここでも許可されます。どの句読点文字でも、日付部分または時間部分の間の区切り文字として使用できます。たとえば、'2012-12-31 11:30:45''2012^12^31 11+30+45''2012/12/31 11*30*45'、および '2012@12@31 11^30^45' は同等です。

    日付および時間の部分と小数秒部分との間の区切り文字として認識される唯一の文字が小数点です。

    日付部分と時間部分は、空白ではなく T で区切ることもできます。たとえば、'2012-12-31 11:30:45''2012-12-31T11:30:45' は同等です。

  • 'YYYYMMDDHHMMSS' または 'YYMMDDHHMMSS' 形式の、区切り文字がない文字列 (日付として適切なもの) として。たとえば、'20070523091528''070523091528''2007-05-23 09:15:28' として解釈されますが、'071122129015' は正しくないため (分の部分が不適切)、'0000-00-00 00:00:00' になります。

  • YYYYMMDDHHMMSS または YYMMDDHHMMSS 形式の数値 (日付として適切なもの) として。たとえば、19830905132800830905132800'1983-09-05 13:28:00' として解釈されます。

DATETIME または TIMESTAMP 値には、マイクロ秒 (6 桁) までの精度の後続の小数秒部分を含めることができます。小数部は、常に時間の残りの部分から小数点で区分する必要があります。これ以外の小数秒区切り文字は認識されません。MySQL の小数秒のサポートの詳細は、セクション11.3.6「時間値での小数秒」を参照してください。

2 桁の年を含む日付の値は、世紀が不明なためあいまいです。MySQL は次のルールを使用して 2 桁の年の値を解釈します。

  • 70-99 の範囲の値は 1970-1999 に変換されます。

  • 00-69 の範囲の値は 2000-2069 に変換されます。

セクション11.3.8「日付での 2 桁の年」も参照してください。

日付部分の区切り文字を含む文字列として指定される値の場合、10 未満の月または日の値に 2 桁を指定する必要はありません。'2015-6-9''2015-06-09' と同じです。同様に、時間部分の区切り文字を含む文字列として指定される値の場合、10 未満の時、分、または秒の値に 2 桁を指定する必要はありません。'2015-10-30 1:2:3''2015-10-30 01:02:03' と同じです。

数値として指定する値は、6、8、12、14 のいずれかの桁数にするようにしてください。数値を 8 桁または 14 桁の長さにすると、YYYYMMDD または YYYYMMDDHHMMSS 形式であり、最初の 4 桁が年であると想定されます。数値を 6 桁または 12 桁の長さにすると、YYMMDD または YYMMDDHHMMSS 形式であり、最初の 2 桁が年であると想定されます。これらの長さではない数字は、いちばん近い長さまで先行ゼロで埋められているかのように解釈されます。

区切り文字がない文字列として指定された値は、その長さに従って解釈されます。8 または 14 文字の長さの文字列の場合、年は最初の 4 文字で表されていると見なされます。そうでなければ、年は最初の 2 文字で表されていると見なされます。文字列は、その文字列に存在するだけの部分について、左から右に順番に、年、月、日、時、分、秒として解釈されます。これは、6 文字より少ない文字列は利用してはいけないということを意味します。たとえば、1999 年 3 月を表すと考えて '9903' を指定しても、MySQL はゼロ日付値に変換します。これは、年および月の値は 9903 であるけれども、日の部分が完全に欠落しているために起こります。ただし、明示的に値ゼロを指定することによって、欠落している月や日の部分を表すことができます。たとえば、'1999-03-00' の値を挿入するには、'990300' を使用します。

MySQL は次の形式で TIME 値を認識します。

  • 'D HH:MM:SS' 形式の文字列として。'HH:MM:SS''HH:MM''D HH:MM''D HH''SS' のいずれかの緩やかな構文も使用できます。この場合、D は日を表し、0 から 34 の値を指定できます。

  • 'HHMMSS' 形式の区切り文字がない文字列 (時間として適切なもの) として。たとえば、'101112''10:11:12' として認識されますが、'109712' は正しくないため (分の部分が不適切)、'00:00:00' になります。

  • HHMMSS 形式の数値 (時間として適切なもの) として。たとえば、101112'10:11:12' として認識されます。SSMMSSHHMMSS の代替形式も認識されます。

後続の小数秒部分は、'D HH:MM:SS.fraction''HH:MM:SS.fraction''HHMMSS.fraction'、および HHMMSS.fraction の時間形式で認識されます。ここで、fraction はマイクロ秒 (6 桁) までの精度で表される小数部分です。小数部は、常に時間の残りの部分から小数点で区分する必要があります。これ以外の小数秒区切り文字は認識されません。MySQL の小数秒のサポートの詳細は、セクション11.3.6「時間値での小数秒」を参照してください。

時間部分の区切り文字を含む文字列として指定される TIME 値の場合、10 未満の時、分、秒の値に 2 桁を指定する必要はありません。'8:3:2''08:03:02' と同じです。


User Comments
  Posted by Hartmut Holzgraefe on February 26, 2013
Be aware that "punctuation character" is a collation specific attribute, e.g. "2012/01/01" will be interpreted as 2012-01-01 with western language collations but not when using e.g. Japanese sjis ...
Sign Up Login You must be logged in to post a comment.