Tijdszone op Shared hosting gewijzigd

Beste leden,
ik heb een vraag over m'n Shared hosting (Reseller).

Ik heb momenteel op bovenstaande hosting een Ritten systeem draaien voor een taxibedrijf. (Alle toekomstige / verleden ritten zitten daarin opgeslaan)
Deze toepassing werkt al 2 jaar perfect zonder problemen, echter ging er gisteren plots e.e.a. mis.
Bepaalde ritten vervroegden 2 uur in de tijd terwijl andere ritten 2 uur werden vertraagd.

Ik ontdekte wat het probleem precies was:
- Rit-Tijdstippen worden bewaard als timestamp in de database.

Probleem:
- Op de Shared host hadden 2 mede-users het verzoek de Timezone van de server te wijzigen. (omdat hun forum tijd verkeerd liep) - De host (Ik noem voorlopig geen namen) heeft dit dan ook (zonder melding!) gedaan.

Gevolg: Alle ritten versprongen 2 uur terug in de tijd.
Daarna: Heeft het Taxibedrijf in kwestie nog ritten ingevoerd in het systeem. (Zonder enig erg te hebben dat alles was versprongen)
(Dus tijdens die 2 uur vervroeging van het systeem)

Vervolgens is de tijd server-instelling terug gewijzigd naar de originele Tijdszone:
- De normale ritten sprongen dus terug naar hun normale tijd. De ritten die tussenin zijn ingevoerd versprongen echter allen 2 uur (naar 2 uur later).

Dit hield in dat het taxibedrijf 2 uur te laat bij z'n klanten stond voor al deze ritten.

Ik vraag me af of een host zomaar een belangrijke instelling zoals de Servertijd kan wijzigen op een Shared hosting Server zonder daarvan (op z'n minst) eerst een melding te geven?

Graag enig advies

Wellicht is de onderstaande code een oplossing voor je?

date_default_timezone_set('Europe/Paris');

Ik begrijp je punt, maar aan de andere kant is het vrij normaal om de timezone zelf te definieren wanneer je software ontwikkeld voor shared hosting.

Ik vraag me af of een host zomaar een belangrijke instelling zoals de Servertijd kan wijzigen op een Shared hosting Server zonder daarvan (op z'n minst) eerst een melding te geven?

Het is niet netjes, maar aan de andere kant: Als het echt belangrijk is zou je moeten zorgen dat je niet afhankelijk bent van een shared hoster. Als je genoegen neemt met een resellerpakket moet je ook genoegen nemen met het feit dat sommige instellingen nu eenmaal buiten je bereik liggen.

Er zijn wel een paar nuances aan je verhaal.

1) de servertijd is niet gewijzigd maar de tijdzone. Dat lijkt een detail maar dat is het niet: het is een belangrijk verschil. De servertijd wijzigen zou zeer kwalijk zijn, de tijdzone wijzigen niet echt, zie hieronder.

2) jouw applicatie slaat tijden op in zogenaamde UNIX timestamps. Deze UNIX timestamps zijn altijd in de UTC tijdzone. Dat houdt in dat je software zelf verantwoordelijk is voor de conversie van UTC naar de lokale tijdzone.

Soms is dat handig (je hebt nooit dubbele tijdstippen zoals bij zomer/wintertijd) maar soms ook niet. Je moet namelijk verdomd goed weten wat je doet als je tijdzone-conversies doet in je applicatie (zoals, zoals Gerron al opmerkt, zorgen dat je zelf beinvloedt welke tijdzone er gebruikt wordt als zijnde 'lokaal'). Als je niet zo goed weet hoe het werkt dan kan je je applicatie beter zo maken dat die met lokale tijden werkt (datatype DATETIME).

Bedenk eens hoe een script zou werken wat ook vanuit het buitenland wordt gebruikt, of wat op een server draait die in het buitenland staat: inderdaad, dan lost het script dat ook zelf op.

Ik vind dit dan ook eerder een kwestie van een slechte scripter, dan van een slechte hoster.

(Al had je hoster beter tegen die andere twee mensen kunnen zeggen dat ze zelf hun tijdzone maar in het script moeten instellen)

Feit blijft, ik wist helemaal niet dat de tijdszone gewijzigd was.
Had de firma geen ritten meer ingegeven was er geen probleem geweest aangezien de tijdszone 's anderdaags gewoon teruggezet werd.

Het probleem is dat er geen enkele melding gegeven werd.

De server staat trouwens ook in Nederland, dus om welke reden zou je die tijdszone als hoster wijzigen naar een ander land? (Ik herhaal, zonder enige vorm van melding!)

2 Mensen vragen om een instelling te wijzigen & heel de server heeft er (mogelijk, in ieder geval ik wel) last van...

Ik ben het inderdaad met je eens dat het nogal dubieus is ineens de tijdzone te wijzigen. Wil de hoster het niet terugdraaien? Hoe dan ook, het is relatief eenvoudig het zelf op te lossen met de reeds gegeven oplossing.

Het is inmiddels opgelost met de gegeven oplossing.
Enkel de ritten die tijdens de 2 wijzigingen werden ingegeven zijn niet meer te achterhalen..
Er zitten dus nog ritten in het systeem die 2 uur te laat zijn.
- Het is niet voor alle ritten mogelijk te zien op welke dag deze zijn ingegeven.

- Het is niet voor alle ritten mogelijk te zien op welke dag deze zijn ingegeven.

Misschien wel... zit er geen 'crdate' in je database ofso?

Nee, die zit er helaas niet in...

Je kunt ook je backups van de afgelopen paar dagen nagaan en kijken wanneer iets is toegevoegd... Beetje omslachtig maar wel een oplossing.