Zoals in een opmerking gezegd, denk ik dat dit grotendeels te maken heeft met persoonlijke voorkeur. In mijn ogen is het gebruik van een Unix-tijdstempel en "legacy" niet-OOP-interfaces niet de manier om het in de toekomst in de wereld van vandaag te doen, bijvoorbeeld, we gebruiken (lees:niet moeten) een INT datatype in onze database om datums op te slaan in Unix Timestamp-formaat, we zouden in plaats daarvan het native type van de database moeten gebruiken, dat meestal een DATE is of DATETIME type dat samenwerkt met PHP's DateTime object (en andere talen) bijna native als het gaat om standaardconversies.
Om een beetje uit te leggen wat ik bedoel met standaardconversies:wanneer u MySQL gebruikt en een waarde terugtrekt naar PHP, krijgt u een ISO-geformatteerde datumstring, waarvan de DateTime class ontleedt in zijn constructor en geeft je een direct bruikbaar object. Om de Unix-tijdstempelroute te gaan, moet je daarentegen strtotime . gebruiken , dan date om het in elk gewenst formaat te krijgen.
Ik noemde al eerder over interoperabiliteit tussen onze PHP-systemen en .NET-systemen. Hoewel er geen specifieke problemen zijn die worden veroorzaakt door het gebruik van een tijdstempel, is het gewoon niet de praktische oplossing, omdat we opnieuw een database gebruiken die een DateTime-waarde retourneert die rechtstreeks door de pijp kan worden verzonden. Als we dit zouden converteren naar een Unix-tijdstempel voor intern gebruik in PHP, zouden we het ook weer moeten converteren als we een antwoord zouden sturen, of een antwoord naar de .NET-toepassing (of moet ik gewoon zeggen API in dit geval) dat is een tijdstempel, en converteer het aan het einde. Door DateTime te gebruiken over de hele linie verlicht het de noodzaak voor welke conversie dan ook en is het hele ontwikkelingsproces eenvoudiger.
Ten slotte, om aan dit alles toe te voegen, zoals je ook in je bericht hebt vermeld, mag je glanzende items gebruiken zoals DateInterval , gemakkelijkere tijdzonering, gemakkelijkere manipulatie en gemakkelijkere opmaak enz. wanneer u DateTime gebruikt en het zijn verwante objectgeoriënteerde partners in crime. Het is gewoon een eenvoudiger ontwikkelingsproces in mijn ogen.
Ik geloof niet, zoals ik in eerste instantie zei, dat hier een "juist" antwoord op is, maar meer een persoonlijke voorkeur op basis van je eigen codeerstijl, en de opmerkingen hierboven weerspiegelen de mijne.
- Ik geloof het op geen enkele manier. Vooral omdat PHP-scripts over het algemeen zulke kortlopende processen zijn.
Ja :)
Zie opmerkingen hierboven over database, het is niet "native" om voor dit doel een Unix Timestamp te gebruiken IMO. Je kunt gewoon ->getTimezone call bellen en sla dit op in de database, gebruik dan ->setTimezone wanneer u hem er weer uittrekt.