There are a variety of places in EViews where you may work with calendar dates. For most purposes, users need not concern themselves with the intricacies of working with dates. Simply enter your dates in familiar text notation and EViews will automatically interpret the string for you.

Those of you who wish to perform more sophisticated operations with dates will, however, need to understand some basic concepts.

In most settings, you may simply use text representations of dates, or date strings. For example, an EViews sample can be set to include only observations falling between two dates specified using date strings such as “May 11, 1997”, “1/10/1990” or “2001q1”. In these settings, EViews understands that you are describing a date and will interpret the string accordingly.

Date information may also be provided in the form of a date number. A date number is a numeric value with special interpretation in EViews as a calendar date. EViews allows you to convert date strings into date numbers which may be manipulated using a variety of tools. These tools allow you to perform standard calendar operations such as finding the number of days or weeks between two dates, the day of the week associated with a given day, or the day and time 36 hours from now.

The remainder of this section summarizes the use of dates in EViews. (See “Strings and Dates” for reference material.) There are several tasks that are central to working with dates:

Before turning to these tasks, we must first provide a bit of background on the characteristics of date strings, date numbers, and a special class of strings called date formats, which are sometimes employed when translating between the former.

Date strings are simply text representations of dates and/or times. Most of the conventional ways of representing days, weeks, months, years, hours, minutes, etc., as text are valid date strings.

To be a bit more concrete, the following are valid date strings in EViews:

As you can see, EViews is able to handle a wide variety of representations of your dates and times. You may use everything from years represented in 1, 2, and 4-digit Arabic form (“1”, “01”, “99”, “1999”), to month names and abbreviations (“January”, “jan”, “Jan”), to quarter designations in Roman numerals (“I” to “IV”), to weekday names and abbreviations (“Monday”, “Mon”), to 12 or 24-hour representations of time (“11:12 pm”, “23:12”). A full list of the recognized date string components is provided in “Date Formats”.

It is worth noting that date string representations may be divided up into those that are unambiguous and those that are ambiguous. Unambiguous date strings have but a single interpretation as a date, while ambiguous date strings may be interpreted in multiple ways.

For example, the following dates may reasonably be deemed unambiguous:

while the following dates are clearly ambiguous:

The first date string in the latter set is ambiguous because we cannot tell which of the three fields is the year, which is the month, and which is the day, since different countries of the world employ different orderings. The second string is ambiguous since we cannot determine the period frequency within the year. The “2” in the string could, for example, refer to the second quarter, month, or even semi-annual in the year. The final string is ambiguous since it could be an example of a time of day in “hour:minute” format (2:04 am), or a date in “year:period” notation (i.e., the fourth month of the year 2002) or “period:year” notation (i.e., the second month of 2004).

In settings where date input is required, EViews will generally accept date string values without requiring you to provide formatting information. It is here that the importance of the distinction between ambiguous and unambiguous date strings is seen. If the date string is unambiguous, the free-format interpretation of the string as a date will produce identical results in all settings. On the other hand, if the date string is ambiguous, EViews will use the context in which the date is being used to determine the most likely interpretation of the string. You may find that ambiguous date strings are neither interpreted consistently nor as desired.

These issues, and methods of getting around the problem of ambiguity, are explored in greater detail in “Translating between Date Strings and Date Numbers”.

Date information is often held in EViews in the form of a date number. A date number is a double precision number corresponding to an instance in time, with the integer portion representing a specific day, and the decimal fraction representing time during the day.

The integer portion of a date number represents the number of days in the Gregorian proleptic calendar since Monday, January 1, A.D. 0001 (a “proleptic” calendar is a calendar that is applied to dates both before and after the calendar was historically adopted). The first representable day, January 1, A.D. 1 has an integer value of 0, while the last representable day, December 31, A.D. 9999, has an integer value of 3652058.

The fractional portion of the date number represents a fraction of the day, with resolution to the millisecond. The fractional values range from 0 (12 midnight) up to (but not including) 1 (12 midnight). A value of 0.25, for example, corresponds to one-quarter of the day, or 6:00 a.m.

It is worth noting that the time of day in an EViews date number is accurate up to a particular millisecond within the day, although it can always be displayed at a lower “precision” (larger unit of time). When date numbers are formatted to lower precisions, they are always rounded down to the requested precision and never rounded up. Thus, when displaying the week or month associated with a date number, EViews always rounds down to the beginning of the week or month.

A date format string (or date format, for short) is a string made up of text expressions that describe how components of a date and time may be encoded in a date string. Date formats are used to provide an explicit description of a date string representation, and may be employed when converting between strings or numbers and date numbers.

Before describing date formats in some detail, we consider a simple example. Suppose that we wish to use the date string “5/11/1997” to represent the date May 11, 1997. The date format corresponding to this text representation is

which indicates that we have, in order, the following components: a one or two-digit month identifier, a “/” separator, a one or two-digit day identifier, a “/” separator, and a 4-digit year identifier.

Alternatively, we might wish to use the string “1997-May-11” to represent the same date. The date format for this string is

since we have a four-digit year, followed by the full name of the month (with first letter capitalized), and the one or two-digit day identifier, all separated by dashes.

Similarly, the ISO 8601 representation for 10 seconds past 1:57 p.m. on this date is “1997-05-11 13:57:10”. The corresponding format is

Here, we have used the capitalized forms of “MM”, “DD”, and “HH” to ensure that we have the required leading zeros.

A full description of the components of a date format is provided below. Some of the more commonly used examples of date formats are listed in the options for the setformat object commands (see, for example, Table::setformat).

A date format may contain one or more of the following string fragments corresponding to various date components. In most cases, there are various upper and lowercase forms of the format component, corresponding either to the presence or absence of leading zeros, or to the case of the string identifiers.

The following format strings are the basic components of a date format:

Year formats use either two or four digit years, with or without leading zeros. The corresponding date format strings are:

The semi-annual format corresponds to a single digit representing the period in the year:

Quarter formats allow for values entered in either standard (Arabic) or Roman numbers:

Month formats may represent two-digit month values with or without leading zeros, three-letter abbreviations for the month, or the full month name. The text identifiers may be all lowercase, all uppercase or “namecase” in which we capitalize the first letter of the month identifier. The corresponding format strings are given by:

Week of the year formats may be specified with or without leading zeros:

Day formats correspond to day of the year, business day of the year, day of the month, or day of the week, in various numeric and text representations.

The time formats correspond to hours (in 12 or 24 hour format), minutes, seconds, and fractional sections, with or without leading zeros and with or without the AM/PM indicator where appropriate.

You may use text to delimit the date format components:

There are times when it is convenient to work with date strings, and times when it is easier to work with date numbers.

For example, when we are describing or viewing a specific date, it is easier to use a “human readable” date string such as “2002-Mar-20”, “3/20/2002”, or “March 20, 2002 12:23 pm” than the date number 730928.515972.

Alternatively, since date strings are merely text representations of dates, working with date numbers is essential when manipulating calendar dates to find elapsed days, months or years, or to find a specific date and time 31 days and 36 hours from now.

Accordingly, translating between string representations of dates and date numbers is one of the more important tasks when performing advanced operations with dates in EViews. These translations occur in many places in EViews, ranging from the interpretation of date strings in sample processing, to the spreadsheet display of series containing date numbers, to the import and export of data from foreign sources.

In most settings, the translations take place automatically, without user involvement. For example, when you enter a sample command of the form

EViews automatically converts the date strings into a range of date numbers. Similarly, when you edit a series that contains date numbers, you typically will enter your data in the form of a date string such as

which EViews will automatically translate into a date number.

In other cases, you will specifically request a translation by using the built-in EViews functions @datestr (to convert a date number to a string) and @dateval (to convert a date string to a date number).

For example, the easiest way to identify the date 1,000 days after May 1, 2000 is first to convert the string value “May 1, 2000” into a date number using @dateval, to manipulate the date number to find the value 1000 days after the original date, and finally to convert the resulting date number back into a string using @datestr. See also “Formatted Conversion” and “Manipulating Date Numbers” for additional details.

All translations between dates strings and date numbers involve one of two methods:

For the most part, you should find that free-format conversion is sufficient for most needs. Nevertheless, in some cases the automatic handling of dates by EViews may not produce the desired results. If this occurs, you should either modify any ambiguous date formats, or specify an explicit formatted conversion to generate date numbers as necessary.

EViews will perform free-format conversions between date strings and numbers whenever: (1) there is an automatic translation between strings and numbers, or (2) when you use one of the translation functions without an explicit date format.

When converting from strings to numbers, EViews will produce a date number using the “most likely” interpretation of the date string. For the most part, you need not concern yourself with the details of the conversion, but if you require additional detail on specific topics (e.g., handling of date intervals, the implicit century cutoff for 2-digit years) see “Free-format Conversion Details”.

When converting from date numbers to strings, EViews will use the global default settings to determine the default date format, and will display all significant information in the date number.

The free-format conversion of unambiguous date strings (see “Date Strings”), to numbers will produce identical results in all settings. The date string:

will be interpreted as the third day of the third month of the year A.D. 1950, and will yield the date value 711918.0. Note that the date value is the smallest associated with the given date, corresponding to 12 midnight.

Similarly, the date string:

is interpreted as the first instance in the third quarter of 1980. EViews will convert this string into the date number representing the smallest date value in that quarter, 722996.0 (12 midnight on July 1, 1980).

If we specify a time string without a corresponding day,

the day portion of the date is set to 0 (effectively, January 1, A.D. 1), yielding a value of 0.91111111 (see “Incomplete Date Numbers”) for details.

Consider also the following ambiguous date string:

While this entry may appear to be ambiguous since the “03” may reasonably refer to either 1903 or 2003, EViews resolves the ambiguity by assuming that if the two-digit year is greater than or equal to 30, the year is assumed to be from the twentieth century, otherwise the year is assumed to be from the twenty first century (see “Two-digit Years” for discussion). Consequently free-format conversion of two-digit years will produce consistent results in all settings.

Converting from ambiguous date strings will yield context sensitive results. In cases involving ambiguity, EViews will determine the most likely translation format by examining surrounding data or applicable settings for clues as to how the date strings should be interpreted.

The following contextual information is used in interpreting ambiguous free-form dates:

To fix ideas, we consider a few simple examples of the use of contextual information.

If you specify an ambiguous sample string, EViews will use the context in which the sample is used, the frequency of the workfile, to determine the relevant period. For example, given the sample statement

and a quarterly workfile, the sample will be set from 1990q1 to 2003q3. If the workfile is monthly, the sample will be set from January 1990 to March 2003.

Suppose instead that you are editing a series spreadsheet where your date numbers are displayed as dates strings using a specified format. In this setting, EViews allows you to enter your values as date strings, instead of having to enter the underlying date numbers. In this context, it is natural for EViews to use the current display format as a hint in interpreting ambiguous data. For example, if the current display format is set to “Month dd, YYYY” then an input of “2/3/4” or “@dateval("2/3/4")” will be interpreted as February the 3rd, 2004. On the other hand, if the current display format is set to “YYYY-MM-DD” then the same input will be interpreted as the March the 4th, 2002.

In settings where an entire series is provided to an EViews procedure, EViews is able to use all of the values in the series to aid in determining the underlying data format. For example, when an alpha series is provided as a date identifier for restructuring a workfile, EViews will first scan all the values of the series in order to decide on the most likely format of all of the data before converting the string in each element into a date number. If the first observation of the series is an ambiguous “2/3/4” but a later observation is “3/20/95” then the “2/3/4” will be interpreted as the 3rd of February 2004 since that is the only order of year, month and day that is consistent with the “3/20/95” observation.

Conversely, when generating new series values with a genr or series assignment statement, EViews processes observation individually and is therefore unable to obtain contextual information to aid in interpreting ambiguous date strings. In this case, EViews will use the global workfile setting for the Month/Day order in dates to determine the ordering of the days and months in the string.

For example, when the expression

is used to generate a series containing date values, EViews will interpret the value as February 3, 2004, if the global setting is Month/Day/Year, and March 2, 2004, if the global setting is Day/Month/Year.

EViews provides the @datestr function to translate a date number to a date string. We describe the function in detail in “Formatted Conversion”, but for now, simply note that @datestr takes an optional argument describing the date format to be used when exporting the string. If the optional argument is not provided, EViews will perform a free-format conversion.

In performing the free-format conversion, EViews examines two pieces of information. First, the global default settings for the Month/Day order in dates will be used to determine the ordering of days and months in the string. Next, EViews examines the date values to be translated and looks for relevant time-of-day information.

If there is no relevant time-of-day information in the date numbers (e.g., the non-integer portions are all zero), EViews writes the string corresponding to the date using either the date format

or

with preference given to the order favored in the global settings.

If there is relevant time-of-day information, EViews will extend the date format accordingly. Thus, if days are favored in the ordering, and relevant hours (but not minutes and seconds) information is present, EViews will use

while if hours-minutes are present, the format will be

and so forth.

While the free-format conversions will generally produce the desired results, there may be times when you want to exercise precise control over the conversion. EViews will perform a formatted conversion between date strings and date numbers whenever you use the @dateval or @datestr functions with the optional second argument specifying an explicit date format.

To convert a date string into a date number using a date format, you should use the @dateval function with two arguments. The first argument must be a valid date string, and the second must be the corresponding date format string. If you omit the optional second argument, EViews will perform a free-format conversion.

A few simple examples will illustrate the wide range of string to date number conversions that are possible using @dateval and a date format. The simplest format strings involve the standard month/day/year date descriptions:

will return the date number for December 1, 1999 (730088),

returns the date number for January 12, 1999 (729765). Here we have changed the interpretation of the date string from “American” to “European” by reversing the order of the parts of the format string.

Likewise, we may find the first date value associated with a given period

returns the value 729754.0 corresponding to 12 midnight on January 1, 1999, the first date value for the year 1999.

Conversion of an broad range of date strings is possible by putting together various date format string components. For example,

returns the date number for 12 midnight on January 12, 1999 (729765), while

yields the value 729765.900694 corresponding to the same date, but at 9:37 in the evening. In this example, the “hm:mi” corresponds to hours (in a 12 hour format, with no leading 0’s) and minutes, and the “am” indicates that there is an indicator for “am” and “pm”. See “Date Strings” and “Date Formats” for additional details.

To translate a date number to a date string using a date format, you should use the @datestr function with two arguments. The first argument must be a valid date number, and the second must be a date format string describing a string representation of the date.

For example,

will return “12/1/99”,

will return “01/12/1999”, and

will return “December 1, 1999”, and

will produce the string “3”, representing the weekday number for December 1, 1999. See “Date Numbers” and “Date Formats” for additional details.

While date information is most commonly held in the form of date strings or date numbers, one will occasionally encounter data in which a date is encoded as a (non-EViews format) numeric value or values. For example, the first quarter of 1991 may be given the numeric representation of 1991.1, or the date “August 15, 2001” may be held in the single number 8152001, or in three numeric values 8, 15, and 2001.

The @makedate function is used to translate ordinary numbers into date numbers. It is similar to @dateval but is designed for cases in which your dates are encoded in one or more numeric values instead of date strings:

The simplest form of @makedate involves converting a single number into a date or a time. The following are the supported formats for converting a single number into a date value:

The following formats are supported for converting a single number into intraday values:

Note that the @makedate format strings are not case sensitive, since the function requires that all non-leading fields must have leading zeros where appropriate. For example, when using the format “YYYYMMDD”, the date March 1, 1992 must be encoded as 19920301, and not 199231, 1992031, or 1992301.

Let us consider some specific examples of @makedate conversion of a single number. You may convert a numeric value for the year into a date number using a format string to describe the year. The expressions:

both return the date number 729754.0 corresponding to 12 midnight on January 1, 1999. Similarly, you may convert a numeric value into the number of hours in a day using expressions of the form,

Here, EViews will return the date value 0.5 corresponding to 12 noon on January 1, A.D. 1. While this particular date value is not intrinsically of interest, it may be combined with other date values to obtain the value for a specific hour in a particular day. For example using date arithmetic, we may add the 0.5 to the 729754.0 value (12 midnight, January 1, 1999) obtained above, yielding the date value for 12 noon on January 1, 1999. We consider these sorts of operations in greater detail in “Manipulating Date Numbers”.

If your number contains “packed” date information, you may interpret the various components using @makedate with an appropriate format string. For example,

all return the value 726526.0, representing March 1, 1990.

Cases where @makedate is used to convert more than one argument into a date or time are more limited and slightly more complex. The arguments must be listed from the lowest frequency to the highest, with the first field representing either the year or the hour, and the remaining fields representing sub-periods. The valid date format strings for the multiple argument @makedate are a subset of the date format strings, with components applied sequentially to the numeric arguments:

Similarly, the valid formats for converting multiple numeric values into a time are:

For convenience, the non-space-delimited forms of these format strings are also supported (e.g., “yymm”, and “hhmi”).

For example, the expressions,

will return the value 729360.0 corresponding to midnight on December 3, 1997. You may provide a subset of this information so that

returns the value 729358.0 representing the earliest date and time in December of 1997 (12 midnight, December 1, 1997). Likewise,

yields the value 729060.0 (February 6, 1997, the 37th day of the year) and

returns the value 0.600810185 corresponding to 2:25:10 pm on January 1, A.D. 1.

It is worth pointing out that in the examples above, the numeric arguments are entered from lowest frequency to high, as required. The following example, in which days appear before months and years, is not a legal specification

and will generate an error reporting a “Bad date format”.

Lastly, we note that limitations on the date formats supported by @makedate imply that in some cases, you are better off working with strings and the @dateval function. In cases, where @makedate does not support a desired conversion, you should consider converting your numbers into strings, performing string concatenation, and then using the richer set of @dateval conversions to obtain the desired date values.

One of the most important reasons for holding your date information in the form of date numbers is so that you may perform sophisticated calendar operations.

Since date values are simply double precision numbers, you may perform standard mathematical operations using these values. While many operations such as division and multiplication do not preserve the notion of a date number, you may find addition and subtraction and relational comparison of date values to be useful tools.

If, for example, you add 7 to a valid date number, you get a value corresponding to the same time exactly seven days later. Adding 0.25 adds one-quarter of a day (6 hours) to the current time. Likewise, subtracting 1 gives the previous day, while subtracting 0.5 gives the date value 12 hours earlier. Taking the difference between two date values yields the number of days between the two values.

While using the addition and subtraction operators is valid, we strongly encourage you to use the EViews specialized date functions since they allow you to perform arithmetic at various frequencies (other than days), while taking account of irregularities in the calendar (see “Functions for Manipulating Dates”).

Similarly, while you may round a date number down to the nearest integer to obtain the first instance in the day, or you may round down to a given precision to find the first instance in a month, quarter or year, the built-in functions provide a set of simple, yet powerful tools for working with dates.

Note further that all of the relational operators are valid for comparing date numbers. Thus, if two date numbers are equal, the “=”, “>=”, and “<=” relational operators all return a 1, while the “<>”, “>”, and “<” comparison operators return a 0. If two date numbers are not equal, “<>” returns a 1 and “=” returns a 0. If the first date number is less than a second date number, the corresponding first date precedes the second in calendar time.

EViews provides several functions for manipulating dates that take date numbers as input and return numeric values that are also date numbers. These functions may be used when you wish to find a new date value associated with a given date number, for example, a date number 3 months before or 37 weeks after a given date and time.

The functions described below all take a time unit string as an argument. As the name suggests, a time unit string is a character representation for a unit of time, such as a month or a year. The valid time unit string values are: “A” or “Y” (annual), “S” (semi-annual), “Q” (quarters), “MM” (months), “WW” (weeks), “DD” (days), “B” (business days), “HH” (hours), “MI” (minutes), “SS” (seconds).

There are three primary functions for manipulating a date number:

Given a date number you may wish to extract numeric values associated with a portion of the value. For example, you might wish to know the value of the month, the year, or the day in the year associated with a given date value. EViews provides the @datepart function to allow you to extract the desired information.

Consider the date1 date value 730110.5 (noon, December 23, 1999). The @datepart values for

are 23 (day of the month), 1 (day in the week), 52 (week in the year), 12 (month in the year), and 99 (year), respectively.

Note that the numeric values returned from @datepart are not themselves date values, but may be used with @makedate to create date values.

In addition to the functions that convert strings or numbers into date values, EViews provides the following special ways to obtain one or more date values of interest.

The remaining functions return information for each observation in the current workfile.

The @date function will generally be used to create a series containing the date value associated with every observation, or as part of a series expression involving date manipulation. For example:

which generates a series containing the date values for every observation, and the date values for every observation 12 weeks from the current values.

@strdate should be used when you wish to obtain the date string associated with every observation in the workfile—for example, to be used as input to an alpha series. It is equivalent to using the @datestr function on the date number associated with every observation in the workfile.

Additional series functions involving dates may be listed in “Workfile Functions”.

EViews supports the free-format conversion of a wide variety of date strings in which the string is analyzed for the most likely corresponding date.

Any of the following date string types are allowed:

The resulting date values correspond to the first instance in the day (12 midnight).

The results are rounded to the first instance in the month (12 midnight of the first day of the month).

The date value is rounded to the first instance in the period in the year

The date value is rounded to the first instance in the year (12 midnight on January 1).

Note that the following conventions may be used in interpreting ambiguous free-form dates.

A date in EViews is generally taken to represent a single point in calendar time. In some contexts, however, a date specification is used to refer to a range of values contained in a time, which can be referred to as an interval.

When a date specification is treated as an interval, the precision with which the date is specified is used to determine the duration of the interval. For example, if a full day specification is provided, such as “Oct 11 1980”, then the interval is taken to run from midnight at the beginning of the day to just before midnight at the end of the day. If only a year is specified, such as “1963”, then the interval is taken to run from midnight on the 1st of January of the year to just before midnight on the 31st of December at the end of the year.

An example where this is used is in setting the sample for a workfile. In this context, pairs of dates are provided to specify which observations in the workfile should be included in the sample. The pairs of dates are provided are processed as intervals, and the sample is defined to run from the start of the first interval to the end of the second interval. As an example, if the sample “1980q2 1980q2” is specified for a daily file, the sample will include all observations from April 1st 1980 to June 30th 1980 inclusive.

An EViews date number can be used to represent both a particular calendar day, and a particular time of day within that day. If no time of day is specified, the time of day is set to midnight at the beginning of the day.

When no date is specified, the day portion of a date is effectively set to 1st Jan A.D. 1. For example, the date string “12 p.m.” will be translated to the date value 0.5 representing 12 noon on January 1, A.D. 1. While this particular date value is probably not of intrinsic interest, it may be combined with other information to obtain meaningful values. See “Manipulating Date Numbers”

In general, EViews interprets years containing only two digits as belonging to either the twentieth or twenty-first centuries, depending on the value of the year. If the two digit year is greater than or equal to 30, the year is assumed to be from the twentieth century and a century prefix of “19” is added to form a four digit year. If the number is less than 30, the year is assumed to be from the twenty first century and a century prefix of “20” is added to form a four digit year.

Note that if you wish to refer to a year after 2029 or a year before 1930, you must use the full four-digit year identifier.

Because this conversion to four digit years is generally performed automatically, it is not possible to specify years less than A.D. 100 using two digit notation. Should the need ever arise to represent these dates, such two digit years can be input directly by specifying the year as a four digit year with leading zeros. For example, the 3rd of April in the year A.D. 23 can be input as “April 3rd 0023”.

In implicit period notation (e.g., “1990:3”), the current workfile frequency is used to determine the period.

When performing a free-format conversion in the absence of contextual information sufficient to identify whether data are provided in “mm/dd” or “dd/mm” format, the global workfile setting for the Options/Dates & Frequency Conversion.../Month/Day order in dates ( “Date Representation”) will be used to determine the ordering of the days and months in the string.

For example, the order of the months and years is ambiguous in the date pair:

so EViews will use the default date settings to determine the desired ordering. We caution you, however, that using default settings to define the interpretation of date strings is not a good idea since a given date string may be interpreted in different ways at different times if your settings change. You may instead use the IEEE standard format, “YYYY-MM-DD” to ensure consistent interpretation of your daily date strings. The presence of a dash in the format means that you must enclose the date in quotes for EViews to accept this format. For example:

will always set the sample to run from January 3, 1991 and July 5, 1995.

Free-format dates can also contain optional trailing time of day information which must follow the pattern:

where “[]” encloses optional portions or the format and “|” indicates one of a number of possibilities. In addition, either the “am” or “pm” field or an explicit minute field must be provided for the input to be recognized as a time. An hour by itself is generally not sufficient.

The time of day in an EViews date is accurate up to a particular millisecond within the day, although any date can always be displayed at a lower precision. When displaying times at a lower precision, the displayed times are always rounded down to the requested precision, and never rounded up.

When both a day and a time of day are specified as part of a date, the two can generally be provided one after the other with the two fields separated by one or more spaces. If, however, the date is being used in a context where EViews does not permit spaces between input fields, a single letter “t” can also be used to separate the day and time so that the entire date can be contained in a single word, e.g. “1990-Jan-03T09:53”.

There are a related set of functions that you may use that provide information on time-zones: @localt, @tz, @tzlist, @tzspec, and @utc.