Zend_Date API remains simplistic and unitary, its design remains flexible and powerful
through the rich permutations of operations and operands.
Several methods use date format strings, in a way similar to PHP's
If you are more comfortable with PHP's date format specifier than with ISO format specifiers,
then you can use
Zend_Date::setOptions(array('format_type' => 'php')).
Afterward, use PHP's date format specifiers for all functions which accept a
Zend_Date::setOptions(array('format_type' => 'iso')) to switch back to the default mode of
supporting only ISO date format tokens. For a list of supported format codes, see
Section 12.6.4, “Self-defined OUTPUT formats using PHP's date() format specifiers”
When dates are manipulated, sometimes they cross over a DST change, normally resulting in the date
losing or gaining an hour. For exmaple, when adding months to a date before a DST change, if the
resulting date is after the DST change, then the resulting date will appear to lose or gain an hour,
resulting in the time value of the date changing. For boundary dates, such as midnight of the first
or last day of a month, adding enough months to cross a date boundary results in the date losing
an hour and becoming the last hour of the preceding month, giving the appearance of an "off by 1"
error. To avoid this situation, the DST change ignored by using the
When crossing the Summer/Winter DST boundary, normally an hour is substracted or added depending
on the date. For example, date math crossing the Spring DST leads to a date having a day value
one less than expected, if the time part of the date was originally 00:00:00. Since Zend_Date
is based on timestamps, and not calendar dates with a time component, the timestamp loses an hour,
resulting in the date having a calendar day value one less than expected.
To prevent such problems use the option
fix_dst, which defaults to true, causing DST
to have no effect on date "math" (
addMOnth(), subMonth()). Use
Zend_Date::setOptions(array('fix_dst' => false)) to enable the subtraction or addition
of the DST adjustment when performing date "math".
If your actual timezone within the instance of
is set to UTC or GMT the option
'fix_dst' will not be used because
these two timezones do not work with DST. When you change the timezone for this instance
again to a timezone which is not UTC or GMT the previous set 'fix_dst' option will be used
again for date "math".
When adding or substracting months from an existing date, the resulting value for the day of
the month might be unexpected, if the original date fell on a day close to the end of the month.
For example, when adding one month to January 31st, people familiar with SQL will expect February
28th as the result. On the other side, people familiar with Excel and OpenOffice will expect
March 3rd as the result. The problem only occurs, if the resulting month does not have the day,
which is set in the original date. For ZF developers, the desired behavior is selectable using
extend_month option to choose either the SQL behaviour, if set to false,
or the spreadsheet behaviour when set to true. The default behaviour for
is false, providing behavior compatible to SQL. By default,
Zend_Date computes month
calculations by truncating dates to the end of the month (if necessary), without wrapping into the
next month when the original date designates a day of the month exceeding the number of days in
the resulting month. Use
Zend_Date::setOptions(array('extend_month' => true));
to make month calculations work like popular spreadsheet programs.
You can speed up
Zend_Date by using an
This speeds up all methods of
Zend_Date when you are using localized data.
For example all methods which accept
Zend_Date::TIME constants would benefit from this. To set an
Zend_Date just use
Zend_Date::setOptions(array('cache' => $adapter));.
Normally the clocks from servers and computers differ from each other.
is able to handle such problems with the help of
Zend_TimeSync. You can set a
Zend_Date::setOptions(array('timesync' => $timeserver)); which
will set the offset between the own actual timestamp and the real actual timestamp for all
instances of Zend_Date. Using this option does not change the timestamp of existing instances.
So best usage is to set it within the bootstrap file.
Once input has been normalized via the creation of a
Zend_Date object, it will have an
associated timezone, but an internal representation using standard
. In order for a date to be rendered in a localized manner, a timezone must be known first. The default
timezone is always GMT/UTC. To examine an object's timezone use
getTimeZone()). To change an
object's timezone, use
setTimeZone()). All manipulations of these objects are assumed to be
relative to this timezone.
Beware of mixing and matching operations with date parts between date objects for different timezones, which
generally produce undesireable results, unless the manipulations are only related to the timestamp.
Zend_Date objects having different timezones generally works, except as just
noted, since dates are normalized to UNIX timestamps on instantiation of
Most methods expect a constant selecting the desired
$part of a date, such as
Zend_Date::HOUR. These constants are valid for all of the functions below. A list of all
available constants is provided in
Section 12.6.2, “List of All Constants”
. If no
$part is specified, then
Zend_Date::TIMESTAMP is assumed. Alternatively, a
user-specified format may be used for
$part, using the same underlying mechanism and format
. If a date object is constructed using an obviously invalid date (e.g. a month number greater than 12),
Zend_Date will throw an exception, unless no specific date format has been selected -i.e.
$part is either
Zend_Date::DATES (a "loose" format).
Example 12.8. User-specified input date format
$date1 = new Zend_Date('Feb 31, 2007', null, 'en_US'); echo $date1, "\n"; // outputs "Mar 3, 2007 12:00:00 AM" $date2 = new Zend_Date('Feb 31, 2007', Zend_Date::DATES, 'en_US'); echo $date2, "\n"; // outputs "Mar 3, 2007 12:00:00 AM" // strictly restricts interpretation to specified format $date3 = new Zend_Date('Feb 31, 2007', 'MM.dd.yyyy'); echo $date3, "\n"; // outputs "Mar 3, 2007 12:00:00 AM"
If the optional
$locale parameter is provided, then the
$locale disambiguates the
$date operand by replacing month and weekday names for string
$date operands, and
even parsing date strings expressed according to the conventions of that locale (see
). The automatic normalization of localized
$date operands of a string type occurs when
$part is one of the
The locale identifies which language should be used to parse month names and weekday names, if the
$date is a string containing a date. If there is no
$date input parameter, then
$locale parameter specifies the locale to use for localizing output (e.g. the date format
for a string representation). Note that the
$date input parameter might actually have a type
name instead (e.g.
addHour()), although that does not prevent the use of
Zend_Date objects as arguments for that parameter. If no
$locale was specified,
then the locale of the current object is used to interpret
$date, or select the localized
format for output.
Since Zend Framework 1.7.0
Zend_Date does also support the usage of an application
wide locale. You can simply set a
Zend_Locale instance to the registry like shown
below. With this notation you can forget about setting the locale manually with each instance when
you want to use the same locale multiple times.
// in your bootstrap file $locale = new Zend_Locale('de_AT'); Zend_Registry::set('Zend_Locale', $locale); // somewhere in your application $date = new Zend_Date('31.Feb.2007');
add(), sub(), compare(), get(), and set() operate generically on dates. In each
case, the operation is performed on the date held in the instance object. The
$date operand is
required for all of these methods, except
get(), and may be a
object, a numeric string, or an integer. These methods assume
$date is a timestamp, if it is
not an object. However, the
$part operand controls which logical part of the two dates are
operated on, allowing operations on parts of the object's date, such as year or minute, even when
$date contains a long form date string, such as, "December 31, 2007 23:59:59". The result of
the operation changes the date in the object, except for
Example 12.9. Operating on Parts of Dates
$date = new Zend_Date(); // $date's timestamp === time() // changes $date by adding 12 hours $date->add('12', Zend_Date::HOUR); print $date;
Convenience methods exist for each combination of the basic operations and several common date parts as
shown in the tables below. These convenience methods help us lazy programmers avoid having to type out the
date part constants
when using the general methods above. Conveniently, they are named by combining a prefix (name of a basic
operation) with a suffix (type of date part), such as
addYear(). In the list below, all
combinations of "Date Parts" and "Basic Operations" exist. For example, the operation "add" exists for each
of these date parts, including
These convenience methods have the same equivalent functionality as the basic operation methods, but expect
string and integer
$date operands containing only the values representing the type indicated by
the suffix of the convenience method. Thus, the names of these methods (e.g. "Year" or "Minute") identify
the units of the
$date operand, when
$date is a string or integer.
Table 12.1. Date Parts
|Timestamp||UNIX timestamp, expressed in seconds elapsed since January 1st, 1970 00:00:00 GMT/UTC.|
|Year||Gregorian calendar year (e.g. 2006)|
|Month||Gregorian calendar month (1-12, localized names supported)|
|24 hour clock||Hours of the day (0-23) denote the hours elapsed, since the start of the day.|
|minute||Minutes of the hour (0-59) denote minutes elapsed, since the start of the hour.|
|Second||Seconds of the minute (0-59) denote the elapsed seconds, since the start of the minute.|
|millisecond||Milliseconds denote thousandths of a second (0-999).
|Weekday||Weekdays are represented numerically as 0 (for Sunday) through 6 (for Saturday).
|Arpa||Arpa dates (i.e. RFC 822 formatted dates) are supported. Output uses either a "GMT" or "Local differential hours+min" format (see section 5 of RFC 822). Before PHP 5.2.2, using the DATE_RFC822 constant with PHP date functions sometimes produces incorrect results. Zend_Date's results are correct. Example:
|Iso||Only complete ISO 8601 dates are supported for output. Example:
The basic operations below can be used instead of the convenience operations for specific date parts, if
is used for the
Table 12.2. Basic Operations
get($part = null, $locale = null)
set($date, $part = null, $locale = null)
add($date, $part = null, $locale = null)
sub($date, $part = null, $locale = null)
copyPart($part, $locale = null)
Returns a cloned object, with only
compare($date, $part = null, $locale = null)
The following basic operations do not have corresponding convenience methods for the date parts listed in Section 12.4, “Zend_Date API Overview” .
Table 12.3. Date Comparison Methods
equals($date, $part = null, $locale = null)
returns true, if
isEarlier($date, $part = null, $locale = null)
returns true, if
isLater($date, $part = null, $locale = null)
returns true, if
Tests if today's year, month, and day match this object's date value, using this object's timezone.
Tests if tomorrow's year, month, and day match this object's date value, using this object's timezone.
Tests if yesterday's year, month, and day match this object's date value, using this object's timezone.
isDate($date, $format = null, $locale = null)
This method checks if a given date is a real date and returns true if all checks are ok. It works like php's checkdate() function but can also check for localized month names and for dates extending the range of checkdate() false
Several methods support retrieving values related to a
Table 12.4. Date Output Methods
toString($format = null, $locale = null)
Invoke directly or via the magic method
Returns an array representation of the selected date according to the conventions of the object's locale. The returned array is equivalent to PHP's getdate() function and includes:
toValue($part = null)
Returns an integer representation of the selected date
get($part = null, $locale = null)
This method returns the
now($locale = null)
This convenience function is equivalent to
Several methods support retrieving values related to a
Table 12.5. Date Output Methods
|Return the precision of the part seconds|
|Set the precision of the part seconds|
Three methods provide access to geographically localized information about the Sun, including the time of sunrise and sunset.
Table 12.6. Miscellaneous Methods
|Return the date's time of sunrise|
|Return the date's time of sunset|
|Return an array with the date's sun dates|