Classe DateTime vs PHP natif date-fonctions

La classe DateTime a certainement un peu de pratique les méthodes et semble globalement supérieure à la native de PHP les fonctions de date comme strtotime, mktime et strftime (et plus). Mais est-il un inconvénient ou une raison pourquoi je ne devrais pas l'utiliser ?

La seule raison pour laquelle je pense qu'il pourrait être plus coûteux de créer une instance d'une classe que de simplement en utilisant une fonction.

Seriez-vous d'accord avec cela ?
T-il un sens à tout pour utiliser un objet DateTime pour des choses simples?
Existe-il d'autres inconvénients ?

Il semble un peu confus pour basculer entre ces deux options, tout le temps, donc j'aimerais avoir de l'espace ce que je préfère faire.

Deux exemples de ma décision serait:

La conversion d'une date à une valeur localisée
Le calcul de l'intervalle de temps entre deux dates

InformationsquelleAutor Anonymous | 2011-12-22

php strtotime

43

Si votre souci est que la création d'une instance de classe est cher et que ça va entraver la performance, alors je crains que vous êtes aboiements le mauvais arbre. Il ne faut jamais envisager l'utilisation de la éprouvées OO approche où il fait sens. Si il est logique d'utiliser la classe DateTime pour effectuer certains calculs de date, puis l'utiliser. Ce n'est pas cher au point où votre application va le sentir en elle, sauf si vous faites quelque chose de fou comme la création de 1 million d'objets DateTime.

Pourquoi DateTime est grand, c'est parce qu'il allège le souci de l'heure d'été en spécifiant le fuseau horaire lors de la création de l'objet. Il est également facile d'obtenir des différences entre les dates ou obtenir intervalles entre les différents objets. Essentiellement, il réduit la quantité d'inquiétude et de codage (mais j'avoue que c'est à tort parfois, j'espère que c'aurez abordée dans la version 5.4 de PHP).

Bas de ligne j'avais toujours l'utiliser.
- plus la plage de date, même en 32 bits de l'environnement PHP, est suffisant pour maintenir un paleobiologist ou un cosmologiste étudier le début ou la fin de l'univers heureux
- Je vois le "handyness' DateTime, mais avez-vous également l'utiliser pour des choses simples comme ceux que je viens d'ajouter à ma question ?
- Je voudrais, parce que nous allons prendre mktime ou strtotime fonctions - ils besoin de certains de l'ordre de paramètres représentant le jour, l'année, le mois, l'heure, etc. Avec DateTime je me permet de créer l'objet en utilisant arbitraire de paramètres comme $date = DateTime::createFromFormat('m H:s D-Y', $weird_user_input); qui peut ensuite être mis en forme pour le timestamp unix ou tout autre format de date que je souhaite. Je peux même préciser le fuseau horaire immédiatement lors de la création de l'objet. Donc oui, je serais certainement l'utiliser car je ne vois vraiment pas où la procédure serait m'aider mieux.
- PHP de la classe DateTime n'est pas près chic comme .net à cet égard. Au moins pas encore. Autant que je vois, c'est limité à 4 chiffres (sans doute parce qu'il utilise PHP vieux de la date/fonctions de temps pour analyser la date)...mais qui ne vous donnent l'étendue de -9999 à 9999...
- Malheureusement, la plupart des bugs n'ont PAS été fixés par 5.4. bugs.php.net/bug.php?id=40743 bugs.php.net/bug.php?id=49914 bugs.php.net/bug.php?id=51051 bugs.php.net/bug.php?id=51557 bugs.php.net/bug.php?id=52480 bugs.php.net/bug.php?id=54340 bugs.php.net/bug.php?id=54655 bugs.php.net/bug.php?id=55253 bugs.php.net/bug.php?id=60873 bugs.php.net/bug.php?id=60960 bugs.php.net/bug.php?id=61022 bugs.php.net/bug.php?id=61311 bugs.php.net/bug.php?id=61530 bugs.php.net/bug.php?id=61955
- Même la création de 1 million d'objets DateTime ne devrait pas être bien pire que l'appel de la fonction strtotime() 1 millions de fois. L'analyse d'une chaîne en date va être le plus grand fardeau par plusieurs ordres de grandeur que les frais généraux de l'instanciation de l'objet. Je ne suis pas sûr au sujet du stockage supplémentaire requise pour un DateTime sur un int, mais il ne sera pas beaucoup, et vous êtes en profitant de la capacité de stocker des années avant de 1902 ou après 2037. En bref, PHP la vieille manière de traiter les dates que ints est plus cassé que d'utiliser DateTime et n'étant pas rompu atouts de petites différences de rendement.
- Vous pouvez vouloir utiliser DateTimeImmutable, de préférence de type DateTime de PHP 5.5 . Voir derickrethans.nl/immutable-datetime.html pour plus d'info
- après la lecture des rapports de bug, il semble que DateTime n'est sûr pour obtenir l'heure actuelle, les augmentations par rapport à l'heure actuelle, et comparer les valeurs (ne pas calculer la différence). Date de l'arithmétique est mauvais, les intervalles ne sont pas en sécurité, il est préférable de s'en tenir à un seul fuseau horaire et l'utilisation setTimeZone pour le régler. Il convient également de noter que le fuseau horaire n'affecte que la mise en forme et n'est pas prise en charge en compte dans les comparaisons.
- Je suis d'accord avec "Si il est logique d'utiliser la classe DateTime pour effectuer certains calculs de date, puis l'utiliser."
- PHP date et mktime() me permet de créer facilement la polyvalente et dynamique de la date et de l'heure des calculs j'ai besoin de l'aide de simples opérateurs arithmétiques. la plupart des cas, même dans une seule ligne. Cependant je les utilise pour le point que je vois un ralentissement significatif. Seulement ensuite, je regarde pour d'autres méthodes. Si vous êtes à la recherche de vitesse dans une fonction ou d'une nécessité, il vaut toujours la peine d'une recherche sur google.
- Voici mon test sur mon i7 8Go Win 7 en cours d'exécution PHP 7.1 sur serveur XAMPP : date function : 4.1662380695343 DateTime class : 7.1334080696106. Ici est le code que j'ai utilisé pour exécuter ce test (pour 1 million de boucles).
- Vous dites unless you do something crazy such as creating 1 million DateTime objects. Ce serait une limite pour vous? J'ai quelques milliers de reccords où je veux courir DateTime. C'est que pour beaucoup ( pour la performance / vitesse op de l'application)
- vous devriez mesurer, même la création d'un million d'objets datetime n'est pas tiré par les cheveux ces jours - le matériel est mieux, nous avons besoin de php 7.2 etc. Toutefois, cela dépend de ce que vous allez faire avec ces objets. Vous pouvez toujours créer 1 objet DateTime et définir un autre timestamp etc. Puisque vous pouvez littéralement mesurer ce qui va se produire dans votre cas, vous n'avez pas à compter sur mon avis. Voici un petit résultat du test, j'ai couru sur mon errance VM - de créer 1 million de DT objets, il a fallu 0.88 secondes. TL;DR: il suffit d'aller pour elle 🙂
- J'ai essayé comme vous l'avez dit. 250k dossiers a couru en 1second. C'est sur PHP53. Nous sommes une migration à 72 atm, donc, le temps que cela touche à la production, il devrait courir encore plus vite.
InformationsquelleAutor N.B.
0

Pour l'enregistrement, j'ai fait l'erreur d'utiliser la classe DateTime. C'était une grosse erreur. Alors qu'il a quelques fonctionnalités intéressantes, mais il ne vaut pas la peine. Je m'explique:

Disons que vous disposez d'un formulaire (avec une date-picker) et les stocker dans la base de données, alors vous avez 3 formats pour représenter la date.
1. En interne, la variable est de type DateTime()
2. Visuellement, la variable affichée à l'utilisateur est une chaîne de format jj-mm-aaaa ou mm-jj-aaaa (cela dépend de la configuration régionale)
3. Dans la base de données, la variable stockée est également une chaîne de caractères au format yyyy-mm-dd (ANSI)
Donc, je fais affaire avec 3 différents types de représentation pour le même type de données

Aussi, disons que vous voulez serialize (json, xml ou tel), c'est la sérialisation:
```
object(stdClass)#1 (1) {
  ["field1"]=>
  object(DateTime)#2 (3) {
    ["date"]=>
    string(26) "2018-12-02 09:14:09.216273"
    ["timezone_type"]=>
    int(3)
    ["timezone"]=>
    string(30) "America/Argentina/Buenos_Aires"
  }
}
```
C'est une vraie douleur pour essayer de sérialiser.
Mon alternative est simple, pour stocker toute temporelle date sous forme de chaîne et je vais le convertir en DateTime seulement si il est besoin.
```
object(stdClass)#3 (1) {
  ["field1"]=>
  string(19) "2018-12-02 09:14:09"
}
```
- Je suis complètement d'accord qu'il faut beaucoup de travail pour avoir DateTime sur une couche de gestion. Dans les cas où il vaut la peine, je vous recommande d'utiliser différents modèles pour différentes couches. Mon point de vue, les modèles ont des chaînes pour les dates, alors que je suis en train de travailler avec DateTime sur la couche de gestion. Je peux recommander AutomapperPlus pour la carte des entités entre les couches. Une bonne interface et de soutien. Nécessaire seulement dans les cas complexes, bien sûr.
- Je pense que vous n'êtes pas dans un meilleur endroit en n'utilisant pas l'objet DateTime parce que peu importe que vous devez toujours considérer ces 3 couches: 1. Comment l'information est utilisée dans le code (programmation orientée objet) 2. La façon dont l'information est stockée dans la base de données (DB type de données natif) 3. La façon dont l'information est affichée/présenté à l'utilisateur final (mise en forme)
- N'est-ce pas exactement l'avantage de l'utilisation de DateTime si? En traitant avec une représentation abstraite de la date, vous êtes toujours libre de format() pour le cas à portée de main. Généralement, n'importe quel objet je vais sérialiser en JSON met en œuvre la JsonSerializable interface, de sorte que je peux formater une date propriétés de la RFC date de chaînes. Pour la base de données, je vais utiliser ANSI dates, et ainsi de suite - c'est vraiment moins douloureux que d'avoir les sorts et les horodatages de partout...
- Dans votre exemple, si vous ne stockez pas de fuseau horaire avec votre chaîne, il ne fonctionnera pas si votre application est utilisée dans différents fuseaux horaires.
- Et c'est exactement le point. Disons 10:15 AM StandardPacific Heure (GMT-8) et notre système de travail à l'échelle mondiale. Alors, disons que nous avons envie de le lire sous GMT-3, nous nous devons lire l'10:15 (gmt-8), puis de le convertir en gtm-3 et de la montrer comme une heure locale. La solution est de le sauver ZOULOU / GMT-0 (Greenwich), afin que la conversion est facile, et nous n'avons pas besoin d'enregistrer le fuseau horaire
InformationsquelleAutor magallanes
0

À l'aide de DateTime() rend le code plus lisible par rapport à l'approche procédurale de la fonction strtotime(), etc. fonctions.
```
if( strtotime( date( 'm/d/Y', strtotime( $strStartDate ) ) ) > strtotime( date( 'm/d/Y', strtotime( '+6 month', strtotime( $strEndDate ) ) ) ) ) {
```
vs
```
if( new DateTime( $strStartDate ) > ( new DateTime( $strEndDate ) )->modify( '+6 month' ) ) {
```
Sur Windows 64 bits machines de développement, PHP est toujours en 32 bits. Il donnera à vos résultats étranges pour les dates au-delà Vendredi 13 Décembre 1901 à 20:45:54 UTC au mardi 19 janvier 2038 03:14:07 UTC
```
echo ( new DateTime( '20 Jan 2038' ) )->format( 'm/d/Y' ) . PHP_EOL; //gives 01/20/2038
echo strtotime( '20 Jan 2038' ); //returns false
```
https://www.php.net/manual/en/function.strtotime.php#refsect1-function.strtotime-notes

Remarque: L'intervalle de validité d'un timestamp est généralement du Vendredi 13 Décembre 1901 à 20:45:54 UTC au mardi 19 janvier 2038 03:14:07 UTC. (Ce sont les dates qui correspondent aux valeurs minimales et maximales pour un entier signé 32 bits.) Avant PHP 5.1.0, pas toutes les plates-formes de soutien timestamps négatifs, votre date portée peut être limitée par le début de l'époque Unix. Cela signifie que les dates antérieures au 1 janvier 1970 ne fonctionnera pas sur Windows, certaines distributions de Linux, et quelques autres systèmes d'exploitation. Pour les versions 64 bits de PHP, l'intervalle de validité d'un timestamp est réellement infini, comme 64 bits peut représenter environ 293 milliards d'années dans les deux sens.

Je ne suis pas sûr de l'heure d'été est correctement géré natif de la date de fonctions de temps.

Je vous conseille d'utiliser DateTime() les fonctions date natif des fonctions du temps.

InformationsquelleAutor Shaunak Sontakke

Vous devez vous connecter pour publier un commentaire.