Zend_Date-Theory.xml 3.8 KB

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