Become Zend Certified

Prepare for the ZCE exam using our quizzes (web or iPad/iPhone). More info...

When you're ready get 7.5% off your exam voucher using voucher CJQNOV23 at the Zend Store

Working with Date Values

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 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 Zend_Date.

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 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 codes as Zend_Locale_Format::getDate(). 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 NULL or Zend_Date::DATES (a "loose" format).

Example 171. User-Specified Input Date Format

= new Zend_Date('Feb 31, 2007'null'en_US');
$date1"\n"// outputs "Mar 3, 2007 12:00:00 AM"

$date2 = new Zend_Date('Feb 31, 2007'Zend_Date::DATES'en_US');
$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');
$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 Zend_Locale_Format::getDate()). The automatic normalization of localized $date operands of a string type occurs when $part is one of the Zend_Date::DATE* or Zend_Date::TIME* 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 is no $date input parameter, then the $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. $hour for 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');

// somewhere in your application
$date = new Zend_Date('31.Feb.2007');

Zend Framework