Problem med systemtiden. LÖST

[SeniorLemuren]

Jag har 2 rader som sparar när en uppdatering äger rum i mySQL. (ASP)

Kod: Markera allt

<% manifestData("reservationDate")=Date %>
<% manifestData("reservationTime")=Time %>

Problemet är att tiden och datumet så klart är från den Svenska servern som jag kör på.

Hur skal jag få Time och Date att visa rätt tid i den zon jag befinner mig (-5 tim)

[SeniorLemuren]

Jag löste det med att skippa Serverns Time Date. Lite Javascript löste det hela.

Kod: Markera allt

var now = new Date(Date.now());
var formattedTime = now.getHours() + ":" + now.getMinutes() + ":" + now.getSeconds();
var formattedDate = now.getFullYear() + "-" + now.getMonth() + "-" + now.getDate();
document.newManifestForm.localDate.value=formattedDate;
document.newManifestForm.localTime.value=formattedTime;

Kod: Markera allt

<input name="localTime" type="hidden">
<input name="localDate" type="hidden">.
.
.
<% manifestData("reservationDate")= request("localDate") %>
<% manifestData("reservationTime")= request("localTime") %>

[Nerre]

Har du tagit hänsyn till att klienten klocka kan gå fel?

[SeniorLemuren]

Om användaren kör automatisk uppdatering av klockan, (Vilket han rekommenderas att göra), så blir det så små avvikelser att det är försumbart.

[Nerre]

Jo men att man litar på användarens klocka är en vanlig orsak till säkerhetsbrister. Beroende på vad klockslaget används till kan man i vissa lägen få problem t.ex. om användaren ställer fram eller bak klockan flera år.

Nu är det kanske inte alls något problem i din applikation, men det var just det jag undrade om du hade reflekterat över. Är det ok att användaren kan skapa poster som egentligen ligger i framtiden?


En vanlig säkerhetsbrist är t.ex. att man genom att ställa tillbaka klockan flera år kan lura datorn att ett certifikat som har gått ut för flera år sen fortfarande är giltigt.

[SeniorLemuren]

Detta datum används inte på något vis i praktiken. Det talar om när ett transportdokument utfärdades och är en funktion som kunden önskar av någon anledning. Det är helt upp till kunden att hantera denna datumstämpel i databasen, den påverkar inte på något vis själva transportdokumenten.

[maDa]

Det korrekta sättet att lösa detta är givetvis att ha rätt tidzon för sin applikation på servern. Jobbar man över tidzoner så är det klokt att spara alla tider som GMT(0)

[limpan4all]

Menar du inte UTC snarare än GMT?

[maDa]

Ja givetvis UTC, vilket är samma som GMT-0

[Nerre]

Formellt sett är ju GMT tiden vid nollmeridianen i Greenwich.

Sen kan väl UTC och GMT diffa med upp till 1 sekund? Man petar in skottsekunder för att hålla skillnaden nere.

[Glenn]

Ja, UTC och GMT är inte detsamma, dom är UNGEFÄR detsamma tills man är nere på sekundnivå.

UTC (Z) är standardtiden, som man sen plockar ut alla tidszoner från, inklusive GMT som ju är en tidszon (vilket inte UTC är).

Tveksamt om det spelar roll för seniorlemuren i detta fallet dock, men ska man standardisera tiden någonstans bär man ju använda UTC istället för GMT oavsett.