Zend Framework: Zend_Date Component Proposal
| Proposed Component Name | Zend_Date |
|---|---|
| Developer Notes | http://framework.zend.com/wiki/display/ZFDEV/Zend_Date |
| Proposers | Thomas Weidner Gavin (Zend-liaison) |
| Revision | 2.0 - 21 July 2006: Reworked proposal ( changed almost everything ) 1.0 - 11 Juni 2006: Initial proposal (wiki revision: 22) |
Table of Contents
1. Overview
Zend_Date is the basic library for the handling of all date, time and calendar-related issues.
2. References
Mailing List
Date and Time related links
- Date and Time Formats from W3C
- ISO 8601
- Date and time notation by country
- Date and Time in Internet - Timestamps
- NPL - Time and Frequency Labratory
- Sources for Time Zone and Daylight Saving Time Data
- Critical and Significant dates
- Program for Atomic Scnyronize
Java
Python
Ruby
Calendars
3. Component Requirements, Constraints, and Acceptance Criteria
- Wrapper functionality
- Lightweight and fast implementation
- Conversion between different locales for date / time
- Conversion between different calendar-formats
- Formatting for date, time, calendar using locales
4. Dependencies on Other Framework Components
- Zend_Exception
- Zend_Locale_Format
5. Theory of Operation
Basics
Zend_Date is a basic wrapper for all date, time functions. It implements also calendar
and some other additional functionality.
Locale aware
Zend_Date formats the output with locales. It can output the standard format for different uses f.e. ISO date,
unix timestamp, SQL dateformat, ...
Zend_Date also can convert between different date / time formats and locales
Calendar functions
Zend_Date can convert between and display in different calendar formats. Julian, Gregorian and so on...
Computed functions
Dates can be added or substracted from other dates. Also a difference between dates can be computed
Standards
Zend_Date has to be aware of the following standards.
- ISO 8601 - Date Time Definition
- RFC 3339 - Internet Date/Time
- RFC 822 - Arpa Mail Format (Date/Time)
6. Milestones / Tasks
7. Class Index
- Zend_Date_Exception
- Zend_Date
8. Use Cases
Define actual Date
Define Date where Input is an ISO Date
Define Date with Unix Timestamp
Define Date where Input is an Locale Defined Datestring
Define Date where Input is an Arab Date
Convert Date to Unix Timestamp
Convert Date to ISO Format
Get actual monthname
Print date formatted with actual locale
Print date formatted with specified locale
9. Class Skeletons
REALISATION
To mention here:
The functions are not to realize as they were shown, instead almost all are aliases for general functions.
In real the realization will look like this :
So the implementation itself will be very small.
Of course we could also do
I think there's no difference in the speed.
Why can't you create an interface for the date conversions? This would allow someone to extend the interface to allow for more date conversions, won't clutter up the main class with so many constants, and make for longer testing and development cycle.
Very simple prototype for the interface, would probably need more methods for the conversions. Would need methods for class to object accepting conversions.
This could be problematic :
What do you mean with "many constants"... there are only a 8 known calendar formats.
- Gregorian
- Julian
- Buddhist
- Chinese
- Hebrew
- Islamic
- Islamic Civil
- Japanese
(and maybe some ancient ones which make no sense in my eyes)
As Zend_Date has to use Zend_Locale, where these Calendar-Formats are defined in the LDML, it would make no sense to allow an interface to extend the class, as the extension would also have to extend the Zend_Locale and the LDML.
There will be an internal class Zend_Date_Calendar where all this functions will reside, maybe also an Abstract layer (hav'nt thought about this 'til now), but these will not be public as for compatibility with LDML and Zend_Locale.
| Zend Feedback Zend_Date is conditionally accepted subject to the conventions, A ZF default locale object should be used in most places where a The Zend_Date API should not preclude the addition of a class to Since Zend_Date offers combined date and time functionality, Add to the requirements: Functionality in Zend_Date that duplicates Zend_Date should be able to output RFC 822 formatted dates. What is the rationale behind choosing to combine all date and time $date = '143465234'; // Input date in Unix Timestamp Format The use of constants instead of function names (e.g. toValue($date, Instances should be serializable. NTP functions should be split to a different class that is not Parsing, normalization, conversion, and formatting function names No toSQL(). The Db Adapter should have a public function accepting a |
A ZF default locale object should be used in most places where a
component or function expects an optional locale object.
The default locale object should be constructed from an instance of
Zend_Config shared by all ZF components.
All parameters which expect locale are OPTIONALLY.
When this parameter is not given, the locale is taken from the
standard locale which is defined by the ZF (Browser, Environment or Config)
The Zend_Date API should not preclude the addition of a class to
manage timestamps or a class to manage only dates, should these
prove necessary for resource or performance reasons. Note that
some functions become more complicated when using only one class
for dates and times, including validating dates and times.
I do not preclude anything ![]()
For now I don't see any reason to split the functions.
Maybe later on when far more development is done and we are seeing
that there is a preformance bonus when splitting them.
Now it's too early to say which is better.
But I think DOT NET and JAVA had thought hard befor they made their
decision for only a DATE-Class. And I dont think that they were wrong.
Since Zend_Date offers combined date and time functionality,
we suggest renaming the class to Zend_DateTime.
To think of it...
Java and Dot Net are both using only a Date-Object instead of renaming it to DateTime.
Both Date-Objects also offer time functionallity, as time is a subset of date.
And second...
Maybe Zend_Calendar could also be a good decision. Take a look at JAVA.
Personally I think that Zend_Date is more descriptive than Zend_DateTime.
Add to the requirements: Functionality in Zend_Date that duplicates
the new object-oriented date extension (due in PHP 5.2?) will be
replaced when available in the default installation of the minimum
version of PHP required by ZF. Effort should be made to provide
wrapper functionality and a compatible API for areas of Zend_Date
that overlap. Please search for occurrences of PHP_FUNCTION in:
http://lxr.php.net/source/php-src/ext/date/php_date.c
http://derickrethans.nl/files/time-qc2006.pdf
Yes... that's complete clear.
As I see, with PHP5.2 most of the expected issues we want to do, are
direct avaiable through PHP itself in standard installation.
The only question is when will the requirements for the framework
be updated to use PHP5.2 ?
I don't think that it's a good approach to detect the PHP Version and
act properly... own functions when <5.2... wrapper when >=5.2
This would make no sense in my eyes for performance reasons.
So as I see, we will have to integrate functionallity for now and
change this to wrap the php5.2-date object.
Functions will be so done that with PHP5.2 wrapping could be done,
with almost not much work.
Zend_Date should be able to output RFC 822 formatted dates.
http://www.w3.org/Protocols/rfc822/#z28
shows the datetime definition for the RFC822 Arpa Mail Format
Prinzipially the output format could be choosen complete free.
Zend_DateTime->format($format);
But the most used and known formats will be predefined.
f.e. Zend_DateTime::RFC822 = 'DDD, DD.MM.YYYY hh:mm:ss' or so.
Zend_DateTime->toString(Zend_DateTime::RFC822); would output a proper RFC822
compilant date string.
What is the rationale behind choosing to combine all date and time
related functionality into one class like .NET instead of like Ruby?
See Pear-Date Class
http://pear.php.net/reference/Date-1.4.2/Date/Date.html
See Java Date Class
http://java.sun.com/j2se/1.5.0/docs/api/java/util/Date.html
I think it is more naturally to let date and time side by side instead of
splitting them in 3 seperated classes.
The use of constants instead of function names (e.g. toValue($date,
Zend_Date::MINUTES) is non-standard amongst most popular languages. We
prefer to avoid overuse of constants, where common function names are
shared by numerous languages for performing the same date-related
tasks. Consider using one function to compute time spans, and others to
return the number of months, years, minutes, seconds, etc. in the
resulting time span.
That's already reworked in a previous version of the proposal.
It's now preffered to have several functions
->getHour ->getMinute
to become details. All the functions are aliases for a global function ->get
Now with the reworking all common functions from other languages
should be present in Zend_DateTime.
Instances should be serializable.
I added this
NTP functions should be split to a different class that is not
required by default.
Should I extract NTP-functionallity to an extra proposal ? (preffered i think)
Or is it enough to make just an extra class Zend_DateTime_NTP ? (makes no sense in my eyes)
Parsing, normalization, conversion, and formatting function names
could benefit from sharing common looking names with other locale-related
classes.
All parsing, normalization and formatting functionallity is done by
Zend_Locale_Format. So all functions are shared with other ZF classes.
No toSQL(). The Db Adapter should have a public function accepting a
Zend_Date object for conversion to the correct format for the DB.
toSQL was erased a couple of versions ago. There's no need for this spezial
functionallity. To format a date object in a proper format someone could do
Zend_DateTime->format($format); and choose the needed formating-rules.
So... I reworked almost the complete proposal to get all points mentioned by you.
Hope I didn't forget something ![]()
Greetings
Thomas
Thomas, I think it looks great.
I have some more comments that are notes I would like to save here for future reference:
Perl and Java combine date and time into one class. Ruby and Python distinguish between calandar dates and simple times. I believe "aware" datetime's reduce the benefits gained by distinguishing using different classes.
Working with calendar dates involves different data and functionality than manipulation of times of the day. Often, we need to work with one or the other, but not both in the same object. I'm less concerned about performance than I am about the complexity of the API.
The word "date" in various languages often means date and time, but not always (see http://docs.python.org/lib/node251.html and http://www.ruby-doc.org/core/classes/Date.html). The words "hour", "minute", and "second" do not appear in the definition of the word "date" (http://www.answers.com/date).
I'm not convinced that the ZF will never have a class implementing only support for dates without times. If this pure-date class exists, what should it be called?
Yes, I completely agree with "integrate functionality for now and change this to wrap the php5.2 date object" when it becomes available, and the minimum version of the framework is upgraded.
Should I extract NTP-functionallity to an extra proposal ? (preffered i think)
Yes, that sounds good.
I'm not convinced that the ZF will never have a class implementing only support for dates without times. If this pure-date class exists, what should it be called?
When we would have to split the class I would do it like this:
Zend_Time // Only Time
Zend_Date extends Zend_Time // Date (and Time if needed)
Zend_Calendar extends Zend_Date // Complete Calendar functionallity
Yes, I completely agree with "integrate functionality for now and change this to wrap the php5.2 date object" when it becomes available, and the minimum version of the framework is upgraded.
I'm not sure if the date-object covers all things I've written in my proposal with Version 5.2. I took a look in about 6-8 different languages and date implementations and wrote them all together, so that all need should be covered ![]()
/me will first make the other proposals ready... maybe /me has then less work than now, as a PHP5.2 prerelease is already avaiable.
/me holds his thumbs ![]()
Should I extract NTP-functionallity to an extra proposal ? (preffered i think)
Yes, that sounds good.
/me banging his head on the floor ![]()
Ahrrr.... could anyone do this ? I've so much to do with my 4 proposals that I am not able to do a 5th one ![]()
I've got a quick question regarding the constants you're passing to and from the Zend_Date object.
I notice in your examples there is a lot of:-
echo $dateobj->getMonth('Zend_Date::MONTHNAME',Zend_Date::DE_DE);
Where DE_DE is a constant of Zend_Date. But how can we perform the same sort of operation to find the value of 'EN_UK' or 'EN_AU' if it is passed as a variable?
e.g.
$to = 'EN_AU';
$from = 'DE_DE';
How can I determine the correct locale value to pass to the getMonth method this way? I'd obviously prefer to have the flexibility not to hard-code constants into my code if they're not strictly necessary.
I notice in your examples there is a lot of:-
echo $dateobj->getMonth('Zend_Date::MONTHNAME',Zend_Date::DE_DE);
Where DE_DE is a constant of Zend_Date. But how can we perform the same sort of operation to find the value of 'EN_UK' or 'EN_AU' if it is passed as a variable?
e.g.
$to = 'EN_AU';
$from = 'DE_DE';
I've forgot to change the examples when I renewed the class skeleton.
First:
getMonth will only return a number representation of the month, and this is locale-independent
When you look at the class skeleton you will also see that getMonth has no parameters.
Zend_Date has no known locales.
So instead of Zend_Date::de_DE is should be Zend_Locale::de_DE.
When you want a month name, which is locale dependent, you can do something like this:
Output the actual month in standard locale
Output in different locale (f.e. fr_FR)
Input date in a different Locale
How can I determine the correct locale value to pass to the getMonth method this way? I'd obviously prefer to have the flexibility not to hard-code constants into my code if they're not strictly necessary.
You don't have to set a locale. All locale-parameters are OPTIONAL !!
Zend_Date will know the standard locale and use it.
When your user uses a different locale you will have to do something like this:
Btw:
Zend_Locale will have a function to let you determinate which locales are avaiable for translation.
Something like this:
Zend_Locale_Data::getRegionList
Zend_Locale_Data::getLocaleList
Zend_Locale->getAvaiableLocales
But all month names will be present for all locales independent from the avaiable translations, as these strings are in LDML.
So you could always do a ->getDayName($locale); even when you have no translation for this locale avaiable.
Thanks Thomas - I understand setting the locale isn't mandatory. My question was based more around the use of constants for the date methods.
So are you saying that the following will still be valid?
$data = new Zend_Date();
$locale = new Zend_Locale('fr_FR');
echo $date->getMonthName($locale);
Yes, that will be valid.
Of course when you make
you will set 'fr_FR' as you new locale.
So you could do
and your set default locale will be used.
It will be the same it you would have written
You will only have to set a spezified locale when you want to create a defined output in a different locale than the one the user sees.
For example when you have a xml file and will write your datas and output in english, independent which language the user has set.
So you could show the user the date in his language and write the same date in a spezified different language.
It's just an idea.
What I really wanted to say is, that you will have the OPTION to set a different lo
ZF Home Page
Code Browser
Wiki Dashboard
A date manipulation and calculation class is a must - I do like the proposal.
I'd be wary of too many specific translators, though like toSQL() or toIslamic() or fromChinese(). Could these be better implemented with flags passed to a more generic function?
$date = new Zend_Date;
$date->fromDate($myvalue, Zend_Date::CALENDAR_CHINESE);
echo $date->toDate(Zend_Date::CALENDAR_HEBREW);
I'd also like to see some sort of day/hour/minute manipulation similar to MySQL's TO_DAYS() function which can be very handy when comparing time spans.