Tijdszones en het verschil tussen server en client

[djluc]

Een bekend probleem, ik kom echter maar niet op een logische oplossing:
Ik heb een CMS: Typo3(PHP) met daarachter een MySQL database. In deze database worden tijden opgeslagen als timestamp. Deze wordt opgeslagen in GMT tijdszone, dus +0.

Ik ben bezig met het maken van een roosterapplicatie. Deze wordt in meerdere tijdszones gebruikt. Hoe ga ik nu om met die tijdszones? Bijvoorbeeld:
Ik ben als Nederlander ingelogd in het CMS. Ik tik dan in: 10:00uur. Dit wordt opgeslagen als: 09:00. Wat is nou logisch? Hoe laat moet ik nu gaan werken? Ik bedoel dus dat je om 10:00uur moet werken.

Ik kom er maar niet uit hoe ik dit nu logisch moet aanpakken. Het probleem gaat namelijk verder: wat gebeurt er als ik nu in het roostersysteem uit een andere tijdszone kijk? Dan zie ik een tijd als: 14:00uur. Wat is nou een logische manier om hier mee om te gaan?

[Mithrandir]

Het lijkt mij het meest logische dat je de gebruiker op elke pagina de keuze geeft: lokale tijd weergeven, GMT tijd weergeven of de eigen zonetijd (als iemand uit een andere zone bijvoorbeeld iemand wil bellen op kantooruren, dan kan hij/zij dus zien hoe laat dat moet).

Op de server zou ik de tijden gewoon als unix timestamp opslaan. Dat is het makkelijkste: ze zijn tijdszone-onafhankelijk; als je in een andere zone de tijd bekijkt is de weergegeven tijd gewoon aangepast.

edit:

Iedere gewenste zonetijd zou natuurlijk ook een idee zijn, maar de vorige mogelijkheden zou ik prominenter op de pagina plaatsen ivm gebruiksvriendelijkheid en overzichtelijkheid.

[ Voor 25% gewijzigd door Mithrandir op 22-12-2005 19:26 ]

[djluc]

Maar wat zet je dan voor het rooster voor Nederland in de database:
Als je om 10:00 uur in Nederland moet werken. Zet je dan 09:00 uur in de database of juist 10:00 uur? Op dit moment denk ik GMT dus 09:00 uur, dat lijkt me het meest bedrijfszeker.

[r0b]

djluc schreef op donderdag 22 december 2005 @ 19:33:
Maar wat zet je dan voor het rooster voor Nederland in de database:
Als je om 10:00 uur in Nederland moet werken. Zet je dan 09:00 uur in de database of juist 10:00 uur? Op dit moment denk ik GMT dus 09:00 uur, dat lijkt me het meest bedrijfszeker.

Per account de keuze geven welke tijdszone ze willen gebruiken, en adv deze keuze de gewenste tijd uit de db trekken en eventueel aanpassen.

Zodra je aan een roosterapplicatie werkt geef je users sowieso al een eigen account (neem ik aan?), dus dat moet dan geen probleem vormen.

[ Voor 13% gewijzigd door r0b op 22-12-2005 19:35 ]

[Adion]

Het lijkt mij ook het meest logische om de gmt tijd in de database te zetten, en bij het tonen opnieuw omrekenen naar de tijdszone van de gebruiker.

Een aantal moeilijkheden die ik me wel kan bedenken:
-Wat als de gebruiker een meeting in een andere tijdszone wil plannen. Zolang dat elke gebruiker steeds in dezelfde tijdszone blijft werken is het geen probleem, hij zal steeds dezelfde uren te zien krijgen. Als diezelfde meeting echter ook met mensen uit die tijdszone moet gepland worden (en dat is in de database dezelfde meeting) dan kan het iets moeilijker worden lijkt me.

-Zomer en wintertijd. Wat als de gebruiker nu een vergadering ingeeft voor volgend jaar. Als hij die meeting vandaag bekijkt krijgt hij gmt +1 te zien, maar een week voor de vergadering krijgt hij dan bijvoorbeeld gmt +2 te zien omdat dan de tijd is veranderd.

[r0b]

Adion schreef op donderdag 22 december 2005 @ 19:47:
-Wat als de gebruiker een meeting in een andere tijdszone wil plannen. Zolang dat elke gebruiker steeds in dezelfde tijdszone blijft werken is het geen probleem, hij zal steeds dezelfde uren te zien krijgen. Als diezelfde meeting echter ook met mensen uit die tijdszone moet gepland worden (en dat is in de database dezelfde meeting) dan kan het iets moeilijker worden lijkt me.

Dan geef je de mogelijkheid hem in GMT+1 te plannen, of welke tijdszone je dan ook maar wilt.
Eventueel met de afkorting van de betreffende tijdszone er voor of achter-aan.

[Mithrandir]

Adion > dat is puur een weergave-'probleem'. Ook met zomer- en wintertijd gaat het helemaal goed als je alle tijden gewoon als GMT en timestamp opslaat zonder tijdzone informatie. Ieder moment heeft een bepaalde waarde, of het nu bijvoorbeeld 'dit' moment hier is, op antarctica, in het donker aan de andere kant van de wereld of 5 kilometer verderop. Dus het opslaan gaat gewoon ok, en ook de weergave van tijden met wel of geen wintertijd gaat gewoon prima; dat zit gewoon in alle systemen die timestamps kunnen weergeven voor users.

[ Voor 4% gewijzigd door Mithrandir op 22-12-2005 19:51 ]

[djluc]

Iedereen heeft inderdaad een eigen account.

Het is inderdaad lastig als je tussen tijdszones moet plannen. Ik denk dat ik beter per rooster een tijdszone kan koppelen. Dat is ook logischer aangezien de werkzaamheden normaal gesproken altijd op 1 locatie plaatsvinden.

Zomer en Wintertijd lijken me niet zo'n groot probleem aangezien de standaard datumfuncties van PHP daar al rekening mee houden.

[Mithrandir]

djluc schreef op donderdag 22 december 2005 @ 20:14:
Iedereen heeft inderdaad een eigen account.

Het is inderdaad lastig als je tussen tijdszones moet plannen. Ik denk dat ik beter per rooster een tijdszone kan koppelen. Dat is ook logischer aangezien de werkzaamheden normaal gesproken altijd op 1 locatie plaatsvinden.

Zomer en Wintertijd lijken me niet zo'n groot probleem aangezien de standaard datumfuncties van PHP daar al rekening mee houden.

Als ik jou was zou ik de mensen ook een optie geven om de tijd in zowel de tijdszone van het project als in de locale tijd te bekijken. Maar dat ligt natuurlijk aan waar het project uiteindelijk voor bedoeld is en hoe de mensen gebruik maken van het rooster.

[DaCoTa]

Mithrandir schreef op donderdag 22 december 2005 @ 19:50:
Adion > dat is puur een weergave-'probleem'. Ook met zomer- en wintertijd gaat het helemaal goed als je alle tijden gewoon als GMT en timestamp opslaat zonder tijdzone informatie. Ieder moment heeft een bepaalde waarde, of het nu bijvoorbeeld 'dit' moment hier is, op antarctica, in het donker aan de andere kant van de wereld of 5 kilometer verderop. Dus het opslaan gaat gewoon ok, en ook de weergave van tijden met wel of geen wintertijd gaat gewoon prima; dat zit gewoon in alle systemen die timestamps kunnen weergeven voor users.

Inderdaad, je moet alle weergaves van GMT rekening laten houden met zowel de locatie als de datum van dat tijdstip. Als je dat doet, gaat alle tijdzone en zomer/winter tijd conversie vanzelf goed. Oftewel, 0:00 GMT is in juli in nederland anders dan 0:00 in december in nederland en is anders dan 0:00 GMT in engeland. Dat betekend dus wel dat je een afspraak altijd op een locatie moet inplannen, anders is je informatie niet volledig. Locatie kan nog wel teruggebracht worden op een tijdzone, maar dat lijkt me wat minder logisch om in te voeren.

[djluc]

Je vat het inderdaad erg logisch samen DaCoTa. Ik denk dat ik per rooster een koppeling maak met de locatie. Vervolgens configureer ik PHP zo dat deze altijd de locale settings gebruikt die gehanteerd worden binnen het rooster. Dat is volgens mij de enige mogelijkheid, niet simpel maar het gaat wel werken zo.

[Tomatoman]

Ik zou als default de tijdzone aanhouden die in de Windowsaccount van de gebruiker is ingesteld. Verder is het misschien handig om te kijken hoe het in Outlook 2003 is opgelost (Tools – Options – Calendar Options – Time Zone). Daar kun je de gewenste tijdzone instellen, maar bovendien kun je een tweede tijdzone weergeven. Naast de kalender staan dan twee tijdweergaves.

[djluc]

Dat is wel een chique feature inderdaad. Bedankt voor de tip, zij hebben al redelijk wat dingen betreffende tijdszones goed doordacht.

[Verwijderd]

Mithrandir schreef op donderdag 22 december 2005 @ 19:50:
Adion > dat is puur een weergave-'probleem'. Ook met zomer- en wintertijd gaat het helemaal goed als je alle tijden gewoon als GMT en timestamp opslaat zonder tijdzone informatie. Ieder moment heeft een bepaalde waarde, of het nu bijvoorbeeld 'dit' moment hier is, op antarctica, in het donker aan de andere kant van de wereld of 5 kilometer verderop. Dus het opslaan gaat gewoon ok, en ook de weergave van tijden met wel of geen wintertijd gaat gewoon prima; dat zit gewoon in alle systemen die timestamps kunnen weergeven voor users.

Hoewel ik met je eens ben dat als je de data in GMT opslaat je altijd een unieke tijd hebt, zul je als je mensen in hun lokale tijd laat plannen toch tegen dubbele tijdstippen aanlopen bij de overgang van zomertijd naar wintertijd. Op die dag heb je tenslotte twee keer het tijdstip 2.15. Bij de representatie zul je dit moeten oplossen.

Een ander probleem is dat ieder land/regio zijn eigen tijd mag kiezen. Dit heeft twee gevolgen.
1) Het gebeurd nog steeds wel eens dat een land van tijdzone veranderd.
2) Er bestaan "rare" tijdzones als GMT + 3.30, +4.30 e.d. (bv Nepal + 5,75 uur)
Dit gekoppeld met de verschillende data van zomer/wintertijd maakt het erg fijn om tijd om de juiste tijd in een bepaald land correct te bepalen.

Maar inderdaad, zorg dat je in je database alles in 1 tijdzone houdt (UTC) en maak het voor de gebruikers mogelijk de tijdzone bij de weergave van de gegevens te kiezen. Het omrekenen van de tijden is geen groot probleem. Lastiger is het om de correcte data te vergaren en een mooie oplossing te bedenken voor de rare momenten bij de omschakeling tussen zomer en wintertijd. Want data invoer en weergave in lokale tijden is in de praktijk een must.

Als je dan toch aan het roosteren bent, houdt dan ook gelijk rekening met het feit dat in verschillende landen de week op een andere dag begint en het weeknummer anders berekend wordt.