| 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374 |
- <?xml version="1.0" encoding="utf-8"?>
- <!-- EN-Revision: 24249 -->
- <!-- Reviewed: no -->
- <sect1 id="zend.date.definition.theory">
- <title>Aspect théorique</title>
- <para>
- Pourquoi n'existe-il que l'unique classe <classname>Zend_Date</classname> pour gérer
- les dates et les heures dans Zend Framework ?
- </para>
- <para>
- Beaucoup de langages divisent la gestion des heures et des dates de calendrier en
- deux classes. Cependant Zend Framework lutte pour une extrême simplicité, et forcer le
- développeur à gérer différents objets avec différentes méthodes pour les heures et les
- dates entraîne un fardeau dans beaucoup de situations. Puisque les méthodes de
- <classname>Zend_Date</classname> supporte le travail avec des dates ambiguës qui
- n'incluraient pas toutes les parties (ère, année, mois, jour, heure, minute, seconde,
- décalage horaire), les développeurs aiment la flexibilité et la facilité d'utilisation
- d'une même classe et des mêmes méthodes afin de réaliser les mêmes actions par exemple
- addition, soustraction, comparaison, fusion de parties de dates, etc.). Diviser la gestion
- de ces fragments de date dans de multiples classes pourraient entraîner des complications
- quand on souhaite réaliser des inter-opérations. Une unique classe réduit la duplication de
- code pour des opérations similaires, sans l'obligation d'une hiérarchie d'héritage
- complexe.
- </para>
- <sect2 id="zend.date.theory.internals">
- <title>Fonctionnement interne</title>
- <itemizedlist mark="opencircle">
- <listitem>
- <para>Référence temporelle <acronym>UNIX</acronym> (timestamp) :</para>
- <para>
- Toutes les dates et heures, même celles ambiguës (par exemple sans
- année), sont représentées en interne par des moments absolus dans le temps,
- stockés en tant que référence temporelle <acronym>UNIX</acronym> exprimant
- la différence entre le moment désiré et le 1er janvier 1970 à 00:00:00
- <acronym>GMT</acronym>. Ceci est seulement possible, parce que
- <classname>Zend_Date</classname> n'est pas limité aux références temporelles
- <acronym>UNIX</acronym> ou aux valeurs entières. L'extension BCMath est
- requise pour supporter les très grandes dates hors de la plage du Vendredi
- 13 décembre 1901 à 20:45:54 <acronym>GMT</acronym> au Mardi 19 janvier 2038
- à 03:14:07 <acronym>GMT</acronym>. De
- plus de petites erreurs mathématiques peuvent apparaître causées par les
- limitations inhérentes aux types de données float et aux arrondis, à moins
- d'utiliser l'extension BCMath.
- </para>
- </listitem>
- <listitem>
- <para>
- Parties de date en tant que décalages de référence temporelle :
- </para>
- <para>
- Ainsi, une instance d'objet représentant trois heures peut être
- exprimé en tant que trois heures après le 1er janvier 1970 à 00:00:00
- <acronym>GMT</acronym> - c'est-à-dire 0 + 3 * 60 * 60 = 10800.
- </para>
- </listitem>
- <listitem>
- <para>Fonctions <acronym>PHP</acronym> :</para>
- <para>
- Quand cela est possible, <classname>Zend_Date</classname> utilise actuellement
- les fonctions <acronym>PHP</acronym> pour améliorer les performances.
- </para>
- </listitem>
- </itemizedlist>
- </sect2>
- </sect1>
|