---

Hej alle.

Jeg sidder og overvejer, eller måske fedter lidt med en datetimepicker.

Det bagvedliggende system kører med en epoc på ~ 01-01-1900

Stardate er noget 'vi' kalder det, men den består at dage.tid siden epoc.

Det her udtryk fungerer p.t:
......
var fromdate = new Date();
alert ('stardate = '+( fromdate.getTime() + (25569 + 2/24 )*86400000 ) /
86400000 );
.......

Men de 2 timers offsedt fra UTC/GMT/ZULU.. time gælder kun når det er
sommertid, ellers er det -1 time.

Findes der en funktion til 'local time' i stedet for at hardcode de 2 timer
?

--
Med venlig hilsen/Best regards
Stig Johansen

---

"Stig Johansen" <wopr.dk@gmail.com> writes:

> Hej alle.
>
> Jeg sidder og overvejer, eller måske fedter lidt med en datetimepicker.
>
> Det bagvedliggende system kører med en epoc på ~ 01-01-1900
>
> Stardate er noget 'vi' kalder det, men den består at dage.tid siden epoc.
>
> Det her udtryk fungerer p.t:
> .....
> var fromdate = new Date();
> alert ('stardate = '+( fromdate.getTime() + (25569 + 2/24 )*86400000 ) /
> 86400000 );
> ......
>
> Men de 2 timers offsedt fra UTC/GMT/ZULU.. time gælder kun når det er
> sommertid, ellers er det -1 time.
>
> Findes der en funktion til 'local time' i stedet for at hardcode de 2 timer
> ?

Ikke umiddelbart. Funktionerne getTime og setTime arbejder på den
underliggende tids-repræsentation i Date-objektet, og den er altid UTC-tid.

Hvad du kan gøre er selv at frætrække tidszone-offset:

function localTime(d) {
// timezone-offset er i minutter.
var localTime = d.getTime() - d.getTimezoneOffset() * 60 * 1000;
return localTime;
}
var d = new Date();
var t = localTime(d);
var stardate = t / 864e5 + 25569;

På den anden side er jeg noget bekymret over at I smider
tidszone-informationen væk. Det vil sige at I faktisk *ikke* køre med en
epoch, men to. Der er to *forskellige* tidspunkter der giver præcist samme
"stardate"!

Prøv
var d1 = new Date(1256430600000);
var d2 = new Date(1256434200000);
var l1 = localTime(d1);
var l2 = localTime(d2);
alert([d1.getTime() == d2.getTime(), l1 == l2])

(Det er de to kl. 2.30'er den 25 oktober, altså når vi går tilbage fra
sommertid).

Det betyder at der tabes information. Det er ikke muligt at gå fra en
stardate til det tilsvarende tidspunkt, lige som det er muligt at lave
en stardate der ikke svarer til noget rigtigt tidspunkt (mellem kl. 2
og kl. 3 den dag vi skifter til sommertid).

Hvis det er muligt, så er det altid bedst at enten gemme tid med tidszone,
eller gemme tid i en fast tidszone (fx UTC).

/L
--
Lasse Reichstein Holst Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

---

Lasse Reichstein Nielsen wrote:

> Hvad du kan gøre er selv at frætrække tidszone-offset:
>
> function localTime(d) {
> // timezone-offset er i minutter.
> var localTime = d.getTime() - d.getTimezoneOffset() * 60 * 1000;

Takker, jeg havde siddet og stirret mig blind på denne her ref:
<http://www.w3schools.com/jsref/jsref_obj_date.asp>
Jeg havde åbenbart ikke læst ordentligt, for getTimezoneOffset() er jo nævnt
B:)

> På den anden side er jeg noget bekymret over at I smider
> tidszone-informationen væk. Det vil sige at I faktisk *ikke* køre med en
> epoch, men to.

Overordnet er jeg enig.
Men det er ikke altid så kritisk (i forhold til indstatsen).

Det her er lidt på tankestadiet, og i første omgang vil jeg bare have den
aktuelle dato/tid præsenteret i 'human readable' format.

Det skal ende med at man vælger et fra - til interval til brug for nogle
database søgninger.

Sandsynligheden for man præcis har behov for at skille 2 records netop i
tidsrummet ved overgang til vintertid er stort set ikke eksisterende, så at
gemme offset for samtlige transaktioner vil være overkill.

Det er egentlig også nærmere på prototype stadiet, så omregning til/fra UTC
i backend er også p.t. lidt (programmeringsmæssigt) overkill.

Men lige nu er 'udfordringen' at (forsøg at) lave en fornuftig timepicker.
Fornuftig - i mine øjne - forstået på den måde, at jeg vil have en 'analog'
picker.

Rullebokse og inputfelter kan være lige meget - it stinks :)

--
Med venlig hilsen
Stig Johansen