repo_zf1/documentation/manual/en/module_specs/Zend_Date-Theory.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- Reviewed: no -->
<sect1 id="zend.date.definition.theory">
    <title>Theory of Operation</title>

    <para>
        Why is there only one class <classname>Zend_Date</classname> for handling dates and times in
        Zend Framework?
    </para>

    <para>
        Many languages split the handling of times and calendar dates into two classes. However,
        Zend Framework strives for extreme simplicity, and forcing the developer to manage different
        objects with different methods for times and dates becomes a burden in many situations.
        Since <classname>Zend_Date</classname> methods support working with ambiguous dates that
        might not include all parts (era, year, month, day, hour, minute, second, timezone),
        developers enjoy the flexibility and ease of using the same class and the same methods to
        perform the same manipulations (e.g. addition, subtraction, comparison, merging of date
        parts, etc.). Splitting the handling of these date fragments into multiple classes would
        create complications when smooth interoperation is desired with a small learning curve. A
        single class reduces code duplication for similar operations, without the need for a complex
        inheritance hierarchy.
    </para>

    <sect2 id="zend.date.theory.internals">
        <title>Internals</title>

        <itemizedlist mark='opencircle'>
            <listitem>
                <para>
                    <acronym>UNIX</acronym> Timestamp
                </para>

                <para>
                    All dates and times, even ambiguous ones (e.g. no year), are represented
                    internally as absolute moments in time, represented as a <acronym>UNIX</acronym>
                    timestamp expressing the difference between the desired time and
                    January 1st, 1970 00:00:00 <acronym>GMT</acronym>. This was only possible,
                    because <classname>Zend_Date</classname> is not limited to
                    <acronym>UNIX</acronym> timestamps nor integer values. The BCMath extension is
                    required to support extremely large dates outside of the range
                    Fri, 13 Dec 1901 20:45:54 <acronym>GMT</acronym> to
                    Tue, 19 Jan 2038 03:14:07 <acronym>GMT</acronym>. Additional, tiny math
                    errors may arise due to the inherent limitations of float data types and
                    rounding, unless using the BCMath extension.
                </para>
            </listitem>

            <listitem>
                <para>
                    Date parts as timestamp offsets
                </para>

                <para>
                    Thus, an instance object representing three hours would be expressed as
                    three hours after January 1st, 1970 00:00:00 <acronym>GMT</acronym>
                    -i.e. 0 + 3 * 60 * 60 = 10800.
                </para>
            </listitem>

            <listitem>
                <para>
                    <acronym>PHP</acronym> functions
                </para>

                <para>
                    Where possible, <classname>Zend_Date</classname> usually uses
                    <acronym>PHP</acronym> functions to improve performance.
                </para>
            </listitem>
        </itemizedlist>
    </sect2>
</sect1>
<!--vim:se ts=4 sw=4 et:-->