The Date Literal

For working with values related to date and time, MySQL supports the temporal literals.Here a distinction is made among date, time, datetime, timestamp, and year literals. These temporal literals are explained in this section and the following sections.

Adate literal,which consists of a year, a month, and a day, represents a certain date on the Gregorian calendar. MySQL allows this literal to be written as an alphanumeric or integer literal. When an alphanumeric literal is used, the entire value must be enclosed in quotation marks, and the three components must be sep-arated by special characters. Usually, the hyphen is used as a character, but other

characters, such as ^/,^@, and ^%, are allowed as well. Irrelevant zeroes can be omitted in the last two components. Examples are shown here:

Date literal Value

--- ---'1980-12-08' December 8, 1980 '1991-6-19' June 19, 1991 '1991@6@19' June 19, 1991

When an integer literal is used to represent a date, the three components are written after each other, thus without hyphens. MySQL interprets the last two digits as the days component, the two digits in front of it as the months component, and everything in front of that as the year component. So be careful with omitting the zeroes. Consider these examples:

In most cases, the years component is specified as a four-digit number. When diverging from this, MySQL uses several rules to determine what exactly is meant.

First, when three digits are specified, a zero is placed in front of it. Second, when the year is specified as a two-digit number, it means that when that number is between 00 and 69, the value 2,000 is added, and if not 1,900 is added. Third, when the year consists of only one digit, three zeroes are placed in front of it. Sev-eral examples help illustrate these rules:

Date literal Value

--- ---'999-10-11' October 11, 0999 551011 October 11, 2055 '99-10-11' October 11, 1999 '9-10-11' October 11, 0009

So MySQL offers many features to specify a date literal. However, we recom-mend largely using the alphanumeric form in which the hyphen is used as the dividing character. This form is easier to read and more explicit, other SQL data-base servers support it, and it seldom gives unexpected results. We also advise always specifying the years component as a four-digit number and relying as little as possible on the rules of MySQL.

Date literals range from 1 January 1000to 31 December 9999and should also represent a date that exists in reality. Only then can MySQL guarantee that all cal-culations with dates are performed correctly. Calcal-culations with dates that are not

within that range could also be performed correctly, but no guarantee is given. Yet two exceptions exist. First, the date '0000-00-00' is allowed. We call this a zero-date.This literal is considered to be a legal date literal and can be used, for exam-ple, to indicate that a certain data is not known yet. Second, each date literal with a legal year component and with a month and/or day component equal to zero is allowed as well. For example, the literals '2006-00-00'and'2006-11-00'are both correct. Both are also called zero-dates. To summarize, the set of correct dates con-sists of all existing dates between 1 January 1000and31 December 9999, including all the zero-dates.

If an incorrect date literal is specified, it is converted into the null value during processing. The ^INSERTstatement forms an exception to this rule. When an incor-rect date is specified, it is converted to the zero-date ^0000-00-00.

Example 5.1: Add an incorrect date to a special table and show the result.

CREATE TABLE INCORRECT_DATES (COLUMN1 DATE) INSERT INTO INCORRECT_DATES VALUES ('2004-13-12') SELECT COLUMN1

FROM INCORRECT_DATES

The result is:

COLUMN1 ---0000-00-00

So the only dates allowed are those that also occur in reality, the so-called exist-ingdates plus those zero-dates. We can deviate from this by turning certain settings on or off.

If we do not want MySQL to accept the zero-date '0000-00-00', we can specify that with a setting of the system variable ^SQL_MODE; see also Section 4.14. If

SQL_MODE has NO_ZERO_DATE as the setting, '0000-00-00' cannot be used. The expressionDATE('0000-00-00')would result in a null value. In this example, noth-ing would change. Even with NO_ZERO_DATE, a null value is stored in the K column.

So with this setting, the set of correct dates becomes smaller.

Another setting is NO_ZERO_IN_DATE. If this setting is used, no zero-dates are accepted for which the month and/or day component is equal to zero. Therefore, the date literal '2006-12-00' is no longer allowed. If both the settings NO_ZERO_DATE

andNO_ZERO_IN_DATEare turned on, the set of correct dates is limited to those dates that fall between 1 January 1000and31 December 9999.

A third important setting is ALLOW_INVALID_DATES. If we give ^SQL_MODEthis set-ting, nonexisting dates can be used. For example, the date literal '2004-2-31'will be accepted even though it does not exist in reality. The only thing that MySQL checks is whether the months component is between ¹and¹²and the days compo-nent is between ¹and³¹. The date literal '2006-14-14'would still not be accepted.

This implies that with this setting, the set of correct dates becomes larger.