Once input has been normalized via the creation of a
object, it will have an associated timezone, but an internal representation using
standard UNIX timestamps.
In order for a date to be rendered in a localized manner, a timezone must be known
first. The default timezone is always GMT or 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. Operating on
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,
Zend_Date::HOUR. These constants are valid for all of the
functions below. A list of all available constants is provided in
list of all constants.
Zend_Date::TIMESTAMP is assumed. Alternatively, a
user-specified format may be used for
$part, using the same
underlying mechanism and format codes as
If a date object is constructed using an obviously invalid date (e.g. a month number
greater than 12), then
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 171. 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
constants. 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
$date input parameter, then the
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
$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
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
// in your bootstrap file
$locale = new Zend_Locale('de_AT');
// somewhere in your application
$date = new Zend_Date('31.Feb.2007');