Beste optie timestamps met verschillende timezones

Of je houdt de GMT tijd (of beter de UTC tijd bij) zodat je vervolgens mensen zelf hun offset kan laten instellen (default + 1 voor Nederland).

Alle timestamps zijn al het goed is afkomstig van jouw server, dus je hebt in je logica maar te maken met 1 timezone.

Alleen bij de weergave heb je meerdere timezones en deze zou ik idd bereiken door uren + / - te doen, DST zegt me zo snel niets, maar als je het alleen maar in je weergave laag stopt zie ik niet zo snel een probleem...

link0007 schreef op donderdag 21 augustus 2008 @ 01:17:
[...]


Hey, wees nou niet te logisch he.. zo zie ik er te stom uit

Klinkt als een goed idee, dan sla ik op zonder DST, geef de gebruiker een selectie voor tijdzone, en kijk dan nog eens naar DST.

Bijvoorbeeld als iemand GMT+2 invult tijdens DST, dan sla ik GMT+1 op. Dan bij het weergeven bekijk ik nog eens of DST aan is, en zo ja dan tel ik nog een uur erbij

Kan best eens lukken ja.. tenzij iemand een probleem ziet met deze methode?

Ja, je moet niet opslaan als GMT+1 maar als GMT/UTC.

link0007 schreef op donderdag 21 augustus 2008 @ 01:17:
Bijvoorbeeld als iemand GMT+2 invult tijdens DST, dan sla ik GMT+1 op. Dan bij het weergeven bekijk ik nog eens of DST aan is, en zo ja dan tel ik nog een uur erbij

Het probleem is echter dat DST niet wereldwijd op hetzelfde moment ingaat, en sowieso niet iedereen aan DST doet.

Megamind schreef op donderdag 21 augustus 2008 @ 01:20:
[...]

Ja, je moet niet opslaan als GMT+1 maar als GMT/UTC.

Beter lezen. Hij zegt dat hij GMT+1 opslaat. Hij zegt niet dat hij de tijd als GMT+1 opslaat. Het gaat dus om de tijdzone die iemand kiest in zijn profiel wat opgeslagen wordt

Gomez12 schreef op donderdag 21 augustus 2008 @ 01:13:
DST zegt me zo snel niets

Daylight Saving Time, oftewel zomertijd

[ Voor 10% gewijzigd door .oisyn op 21-08-2008 01:32 ]

kijk anders eens in de source van phpbb o.i.d.

Sowieso opslaan als UTC/GMT (is dezelfde tijdzone, maar niet exact, UTC is preciezer)
Dus gewoon je server syncen met een goede NTP-server, en die timestamp opslaan.
Je zou een unix timestamp kunnen gebruiken, maar die houden op in 2038.

Dan bereken je de tijd door de instellingen in hun profiel, Dus UTC+1, UTC+2 etc..
Vinkje voor DST erbij en je bent klaar. Als DST in effect treed gewoon UTC+$useroffset+1

Dan laat je DST gewoon ingaan wanneer het hier ingaat ofzo, áls er dan verschillen ontstaan is het maximaal 1 uur, en eigenlijk zit de fout alleen in de weergave naar de gebruiker toe, want de timestamp op je server is toch UTC en verandert niet mee met DST.
Je kan het toch niet helemaal perfect doen, dus dan lijkt me dit de beste oplossing.

[ Voor 6% gewijzigd door mace op 21-08-2008 01:40 ]

mace schreef op donderdag 21 augustus 2008 @ 01:39:
Dan laat je DST gewoon ingaan wanneer het hier ingaat ofzo, áls er dan verschillen ontstaan is het maximaal 1 uur

Tenzij je op het zuidelijk halfrond woont, dan is het maximale verschil 2 uur (want die passen DST juist toe als het voor hún zomer (en dus voor ons winter) is). En het Australische eiland Lord Howe werkt bijvoorbeeld met een half uur DST ipv een heel uur.

[ Voor 9% gewijzigd door .oisyn op 21-08-2008 02:02 ]

Nee, je moet gewoon de UTC tijd opvragen van de server, en niet zelf moeilijk gaan zitten rekenen. Met timestamps zit je overigens altijd goed, die meten namelijk vanaf een vast moment in UTC. Als je dat als UTC (GMT) wilt formatten kun je gmdate() gebruiken, maar ik zou niet weten waarom je dat zou willen doen.

Btw

mace schreef op donderdag 21 augustus 2008 @ 01:39:
Je zou een unix timestamp kunnen gebruiken, maar die houden op in 2038.

Unix timestamps houden niet ineens op in 2038. Alleen na dat jaar passen ze niet meer in een signed 32 bits int, dus het is wellicht handig om de kolom in de database groter dan 32 bits te maken. De gangbare C implementaties ondersteunen allang een 64 bits time() functie, dus PHP zal tzt ook wel automagisch overgaan.

[ Voor 67% gewijzigd door .oisyn op 21-08-2008 02:11 ]

.oisyn schreef op donderdag 21 augustus 2008 @ 01:52:
[...]

Tenzij je op het zuidelijk halfrond woont, dan is het maximale verschil 2 uur (want die passen DST juist toe als het voor hún zomer (en dus voor ons winter) is). En het Australische eiland Lord Howe werkt bijvoorbeeld met een half uur DST ipv een heel uur.

Aha, dat wist ik niet, maar dat is natuurlijk heel logisch.

[ Voor 4% gewijzigd door mace op 21-08-2008 09:42 ]

.oisyn schreef op donderdag 21 augustus 2008 @ 02:00:
dus het is wellicht handig om de kolom in de database groter dan 32 bits te maken.

...als je zeker weet dat de applicatie de komende 30 jaar op precies dezelfde database draait en je zeker weet dat het even updaten van de databasekolom naar 64 bits in 2038 meer moeite / resources kost dan de extra resources die je systeem gedurende de komende 30 jaar gebruiken gaat, omdat hij gedurende 30 jaar een 64 bits int gebruikt terwijl een 32 bits voldoende is.

/rant

Wikipedia: ISO 8601

Het enige dat interessant is, is hoeveel uur je tijd verschilt van GMT. Of er wel of geen sprake van DST was, is niet relevant. (Waarmee ik bedoel: je moet het niet los registreren. Het moet wel in het tijdsverschil verwerkt zijn)

[ Voor 18% gewijzigd door Confusion op 21-08-2008 22:35 ]

YopY schreef op donderdag 21 augustus 2008 @ 22:18:
[...]


...als je zeker weet dat de applicatie de komende 30 jaar op precies dezelfde database draait en je zeker weet dat het even updaten van de databasekolom naar 64 bits in 2038 meer moeite / resources kost dan de extra resources die je systeem gedurende de komende 30 jaar gebruiken gaat, omdat hij gedurende 30 jaar een 64 bits int gebruikt terwijl een 32 bits voldoende is.

/rant

Precies zo dachten de mensen 30 jaar geleden toen ze jaartallen gingen coderen met 2 decimalen. Je zou denken dat we inmiddels wel wat geleerd hebben. Maar nee, het zou natuurlijk absurd zijn om te denken dat de software over 20 jaar nog draait.

/rant

[ Voor 13% gewijzigd door .oisyn op 21-08-2008 23:07 ]

PHP kan dat helemaal zelf voor je oplossen middels date_default_timezone_set(). Aan het begin van je script de tijdzone van de gebruiker erin stoppen en gaan met die banaan...

.oisyn in "Beste optie timestamps met verschillende...". De ingestelde tijdzone heeft dus helemaal geen invloed op functies als time() en gmdate(). En van date() getdate(), en localtime() en consorten (oftewel, alles wat met de lokale representatie van de huidige tijd te maken heeft) moet je sowieso afblijven als je tijden op wilt gaan slaan.

[ Voor 71% gewijzigd door .oisyn op 22-08-2008 17:44 ]