Som sagt i en kommentar tror jeg, at dette for det meste skyldes personlige præferencer. I mine øjne er brugen af et Unix-tidsstempel og "legacy" ikke-OOP-grænseflader ikke måden at gøre det fremadrettet på i dagens verden, for eksempel bruger vi (læs:burde ikke) ikke en INT datatype i vores database for at gemme datoer i Unix-tidsstempelformat, bør vi i stedet bruge databasens oprindelige type, som normalt er en DATE eller DATETIME type, der samarbejder med PHP's DateTime objekt (og andre sprogs) næsten oprindeligt, når det kommer til standardkonverteringer.
For at uddybe lidt hvad jeg mener med standardkonverteringer:Når du bruger MySQL og trækker en værdi tilbage til PHP får du en ISO-formateret datostreng, hvoraf DateTime klasse analyserer i dets konstruktør, hvilket giver dig et umiddelbart brugbart objekt. I modsætning hertil skal du bruge strtotime for at gå Unix-tidsstempelruten , så date for at få det til det format, du vil have.
Jeg nævnte før om interop mellem vores PHP-systemer og .NET-systemer. Selvom der ikke er nogen specifikke problemer forårsaget af at bruge et tidsstempel, er det simpelthen ikke den praktiske løsning, da vi igen bruger en database, der returnerer en DateTime-værdi, som kan sendes direkte ned ad røret. Hvis vi skulle konvertere dette til et unix-tidsstempel til brug internt i PHP, skulle vi også konvertere det ud igen, hvis vi skulle sende et svar eller sende et svar til .NET-applikationen (eller skulle jeg bare sige API i dette tilfælde), som er et tidsstempel, og konverter det til sidst. Ved at bruge DateTime over hele linjen afhjælper det behovet for, at enhver konvertering skal ske overhovedet, og hele udviklingsprocessen er lettere.
Til sidst for at tilføje alt dette, som du også nævnte i dit indlæg, kan du bruge skinnende elementer såsom DateInterval , lettere tidszoneinddeling, lettere manipulation og lettere formatering osv., når du bruger DateTime og det er relaterede objektorienterede partnere i kriminalitet. Det er bare en nemmere udviklingsproces i mine øjne.
Jeg tror ikke, som jeg først sagde, at der er et "korrekt" svar på dette, bare mere en personlig præference baseret på din egen kodningsstil, og kommentarerne ovenfor afspejler min.
- Det tror jeg ikke på nogen måde. Især med PHP-scripts, der generelt er så korte processer alligevel.
Ja :)
Se kommentarer ovenfor om databasen, det er ikke "native" at bruge et Unix-tidsstempel til dette formål IMO. Du kan bare ringe til ->getTimezone og gem dette i databasen, brug derefter ->setTimezone når du trækker den ud igen.