[FRAGE] new Date und formatierung/kalkulation-Funktionen

[Paykoman]

Hallo Forum,

nun ich bastel einwenig mit den Date Sachen in JS, ich habe mir ne kleine Prototyp Funktion geschrieben, diese liefert mir nach meinen Wünschen einen Zeit-string nach meinem Wunschfomat in UTC oder local.

Date.prototype.dateTime = function( output, utc )
{
    var string = ( typeof output != 'undefined' && output != '' ) ? output : "yyyy-mm-dd hh:mi:se";
    var UTC = ( typeof utc != 'undefined' ) ? utc : true;
    if( UTC === false )
    {
        var yyyy = this.getFullYear().toString();
        var mm = (this.getMonth()+1).toString(); // getMonth() is zero-based
        var dd  = this.getDate().toString();
        var hh = this.getHours().toString();
        var mi = this.getMinutes().toString();
        var se = this.getSeconds().toString();
    }
    else
    {
        var yyyy = this.getUTCFullYear().toString();
        var mm = (this.getUTCMonth()+1).toString(); // getMonth() is zero-based
        var dd  = this.getUTCDate().toString();
        var hh = this.getUTCHours().toString();
        var mi = this.getUTCMinutes().toString();
        var se = this.getUTCSeconds().toString();
    }
    
    return string.replace('yyyy', yyyy)
                .replace('mm', (mm[1]?mm:"0"+mm[0]))
                .replace('dd', (dd[1]?dd:"0"+dd[0]))
                .replace('hh', (hh[1]?hh:"0"+hh[0]))
                .replace('mi', (mi[1]?mi:"0"+mi[0]))
                .replace('se', (se[1]?se:"0"+se[0]));
};
var datum = new Date().dateTime();
console.log( datum ); // 2015-10-01 12:37:25
var datum = new Date().dateTime('', false);
console.log( datum ); // 2015-10-01 14:37:25

So das klappt wunderbar, möchte ich nen Datum als String ausgeben setzte ich UTC auf false und der User bekommt die local Zeit, für die Datenbank brauch ich keine Parameter da reicht ja dann new Date().dateTime(); und ich habe den Sting in UTC für die Datenbank umgehend zur Hand.

Soweit, so gut. Wie berechnet JS jedoch die Lokale-Zeit? Sicher auf Grund der Servereinstellung oder doch vom Browser (Client seitig)?
Bei den "Date Object Methods" ist nämlich nichts zu finden das es ermöglichen würde eine Zeitzone zusetzten, denn da ich in der Datenbank alles nach UTC abspeichere muss ich bei Ausgabe eines Datums aus der Datenbank den String in die User-Zeitzone umrechnen und in JS habe ich kein Schimmer wo ich anfangen soll (in php habe ich derartige Funkionen bereits umgesetzt).
Zudem möchte ich diese dann auch auf meinem NODE-js-Server nutzten wo es sicher wieder anders aussieht.


Ich hoffe ihr könnt mir weiter helfen.
MFG: Paykoman

 

[tsseh]

nun ich bastel einwenig mit den Date Sachen in JS, ich habe mir ne kleine Prototyp Funktion geschrieben, diese liefert mir nach meinen Wünschen einen Zeit-string nach meinem Wunschfomat in UTC oder local.

https://developer.mozilla.org/en-US...erence/Global_Objects/Date/toLocaleDateString

Soweit, so gut. Wie berechnet JS jedoch die Lokale-Zeit? Sicher auf Grund der Servereinstellung oder doch vom Browser (Client seitig)?

je nachdem, wo der code läuft

Bei den "Date Object Methods" ist nämlich nichts zu finden das es ermöglichen würde eine Zeitzone zusetzten

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse

aber wenn du die zeit als utc hast, musst du diese doch nicht umrechnen, das macht die date-string-konvertierung für dich, bzw ist das ja keine umrechnung, sondern tatsächlich nur eine formatierung/anpassen eines offsets

 

[kkapsner]

Aus https://developer.mozilla.org/en-US...ference/Global_Objects/Date/getTimezoneOffset kannst du indirekt die Zeitzone ablesen... aber setzen kannst du die nicht.

 

[tsseh]

aber setzen kannst du die nicht.

doch, hab ich doch verlinkt, über parse oder den konstruktor kannst du die auch selbst setzen
es ist nur nicht nötig.

 

[kkapsner]

Dass man auch einen String mit einer anderen Zeitzone einlesen kann hat ja auch keiner bestritten. Aber die Date-Objekte haben immer die Zeitzone, die im Browser eingestellt ist:

d = new Date('Wed, 09 Aug 1995 00:00:00 GMT');
console.log(d.getTimezoneOffset()); //-120

Außerdem gibt es keine setTimezoneOffset-Funktion.

 

[tsseh]

Dass man auch einen String mit einer anderen Zeitzone einlesen kann hat ja auch keiner bestritten.

setzen oder einlesen, wo ist da der unterschied?

Aber die Date-Objekte haben immer die Zeitzone, die im Browser eingestellt ist

Date-Objekte haben immer die Zeitzone GMTaber egal, selbst wenn sie immer die lokale zeitzone hätten, was macht das für einen unterschied(außer dass du beim übergang sommer/winterzeit probleme bekommen würdest)?

Außerdem gibt es keine setTimezoneOffset-Funktion.

nein, aber einen construktor, und parse, sagte ich ja schon

var d1 = new Date('02 Oct 2015 00:00:00 GMT-0400');
var d2 = new Date('02 Oct 2015 00:00:00');
var d3 = new Date(d1.toUTCString() + '+0600'); // für MESZ bei MEZ +5 oder besser +(4+d2.getTimezoneOffset())
console.log(d2-d3);

 

[kkapsner]

setzen oder einlesen, wo ist da der unterschied?

Ist die Frage wirklich ernst gemeint?

Date-Objekte haben immer die Zeitzone GMTaber egal, selbst wenn sie immer die lokale zeitzone hätten, was macht das für einen unterschied(außer dass du beim übergang sommer/winterzeit probleme bekommen würdest)?

Äh... nein... Date-Objekte haben immer die Zeitzone des Browsers (bzw. der Systemuhr). Oder was gibt bei dir

var d = new Date();
console.log(d.getTimezoneOffset());

aus?

Natürlich wird intern alles in UTC gespeichert und kann ja auch mit den UTC-Funktionen ausgelesen werden. Aber .getHour() liefert dir immer das Ergebnis mit einer Zeitzone.

nein, aber einen construktor, und parse, sagte ich ja schon

Die aber nur parsen und nicht die Zeitzone an dem Objekt anpassen, was ich auch schon sagte.

Und der Konstruktor hat keinen Parameter, mit dem man die Zeitzone setzen kann: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date - nur beim Parsen werden die Offsets berücksichtigt. Es ist ja auch in ECAM-262 so definiert, dass der Konstruktor die parse-Funktion aufruft, wenn er einen String bekommt. Also kennt wirklich nur die Date.parse andere Zeitzonen...

4+d2.getTimezoneOffset()

Wirklich? https://developer.mozilla.org/en-US...ference/Global_Objects/Date/getTimezoneOffset

@Paykoman: die Funktion https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleString könnte für dich auch interessant sein.

 

[tsseh]

Ist die Frage wirklich ernst gemeint?

ja

Äh... nein... Date-Objekte haben immer die Zeitzone des Browsers (bzw. der Systemuhr).

Äh... doch... , sagst du ja weiter unten auch, ich komm nicht mehr ganz mit...

Oder was gibt bei dir

var d = new Date();
console.log(d.getTimezoneOffset());

aus?

was hat das mit der frage zu tun? getTimezoneOffset liefert den offset der lokalen timezone zur gmt.

Natürlich wird intern alles in UTC gespeichert und kann ja auch mit den UTC-Funktionen ausgelesen werden. Aber .getHour() liefert dir immer das Ergebnis mit einer Zeitzone.

ja logisch, und getUTCHours immer in gmt
mehr zeitzonen als die lokale zeitzone und die gmt benötigt man idR nicht

Die aber nur parsen und nicht die Zeitzone an dem Objekt anpassen, was ich auch schon sagte.

was aber möglich ist, wie mein beispiel zeigte

Und der Konstruktor hat keinen Parameter, mit dem man die Zeitzone setzen kann:

ob man nun parst, weil wie beim TO die zeit als string vorliegt, oder den offset auf den ms-wert oder den h-wert draufrechnet spielt keine rolle

var d4 = new Date(d1 - 21600000);

nur beim Parsen werden die Offsets berücksichtigt. Es ist ja auch in ECAM-262 so definiert, dass der Konstruktor die parse-Funktion aufruft, wenn er einen String bekommt.

nein, einen Offsets kann man auch selbst einfach dazurechnen

Also kennt wirklich nur die Date.parse andere Zeitzonen...

nein, das ist ja dass, was ich ihm gerade sagen will, die zeitzonen sind nur ein offset, der ist erst mal sch... egal. wenn ich eine utc zeit vorliegen habe, ist das das selbe, als wenn ich dieselbe zeit in als MESZ minus 2h plus offset 2h vorliegen habe. intern ist das immer die selbe zeit. sinnigerweise im utc format.
hat er nun die utc-zeit vorliegen, kann er die einfach einlesen aus seiner datenbank. klar könnte er auch 2h abziehen und sie als MESZ einlesen, das wäre aber sinnlos.
und wenn er das auf dem server macht, und in client-lokaler-zeit ausgeben will, dann rechnet er einfach seinen offset vorher ab
sprich der server rechnet alles in GMT und die ausgabe erfolgt in client-lokaler-zeit

Wirklich? https://developer.mozilla.org/en-US...ference/Global_Objects/Date/getTimezoneOffset

ja wirklich, 4h +120min ist ein offset von 21600s

 

[kkapsner]

ja

Einlesen findet beim Erzeugen des Date-Objektes statt. Setzen wenn es schon existiert...

getTimezoneOffset liefert den offset der lokalen timezone zur gmt.

Nein, das liefert das Offset des Date-Objektes. Das muss nicht immer die gleiche sin wie die lokale Zeitzone des Rechners. So sind wir ja gerade in MEST. Wenn du dir jetzt aber ein Date-Objekt vom Januar erzeugst (oder eines dahin verschiebst) hat es EST. Der Offset ist also an das Objekt gebunden - kann aber durch JS direkt nicht verändert werden. Das ist meine Aussage.

mehr zeitzonen als die lokale zeitzone und die gmt benötigt man idR nicht

Ja und? Ich hab' nur gesagt, dass man es nicht setzen kann...

was aber möglich ist, wie mein beispiel zeigte

In welchem deiner Beispiele hast du die Zeitzone des Date-Objektes geändert? Und mit anderer Zeitzone meine ich nicht, dass du einfach ein paar Stunden addierst oder subtrahierst, sondern dass .getTimezoneOffset() was anderes liefert, denn das ist die Zeitzon des Objektes.

ob man nun parst, weil wie beim TO die zeit als string vorliegt, oder den offset auf den ms-wert oder den h-wert draufrechnet spielt keine rolle

Doch - wenn du gescheit mit Zeiten rechnen willst, musst du immer nach UTC gehen. Und wenn du dann irgendwas "draufrechnest" bist du schon falsch.

nein, einen Offsets kann man auch selbst einfach dazurechnen

Dann ist aber die UTC-Zeit falsch...

nein, das ist ja dass, was ich ihm gerade sagen will, die zeitzonen sind nur ein offset, der ist erst mal sch... egal. wenn ich eine utc zeit vorliegen habe, ist das das selbe, als wenn ich dieselbe zeit in als MESZ minus 2h plus offset 2h vorliegen habe. intern ist das immer die selbe zeit. sinnigerweise im utc format.

Äh... du wiedersprichst dir selbst. Wenn du einen Offset "draufrechnest" hast du eben inter nicht mehr das gleiche...

hat er nun die utc-zeit vorliegen, kann er die einfach einlesen aus seiner datenbank. klar könnte er auch 2h abziehen und sie als MESZ einlesen, das wäre aber sinnlos.
und wenn er das auf dem server macht, und in client-lokaler-zeit ausgeben will, dann rechnet er einfach seinen offset vorher ab
sprich der server rechnet alles in GMT und die ausgabe erfolgt in client-lokaler-zeit

Ja, dass man Zeiten am besten in UTC speichert ist mir klar. Dem Client die Berechnung der lokalen Zeit zu überlasse ist ganz meine Meinung. Den Offset eines Date-Objektes kann man mit .setTimezoneOffset() auslesen, aber man kann den Offset eines Date-Objektes für eine andere Ausgabe von z.B. .getHour() nicht ändern.
Das war mein Statement.

Aber wie ich sehe, ist das hier wieder so eine komplett unproduktive Diskussion... meinen Punkt hab' ich ja schon in #5 klar gemacht: es gibt .getTimezoneOffset() aber nicht .setTimezoneOffset(). Ich bin raus (außer Paykoman hat noch eine konkrete Frage).

PS:

ja wirklich

4+d2.getTimezoneOffset()=124 nicht 21600s - JS kennt keine Einheiten (und oben hast du die Einheiten auch nicht dazugeschrieben)! Wenn du was schreibst, schreibe es gescheit!

 

[tsseh]

Einlesen findet beim Erzeugen des Date-Objektes statt. Setzen wenn es schon existiert...

und was ist dann x=x+1 oder x+=1?
erzeugen, ändern wieder zuweisen, es sind variablen

Nein, das liefert das Offset des Date-Objektes.

das date offset hat kein offset, nur deine lokale zeitzone

Das muss nicht immer die gleiche sin wie die lokale Zeitzone des Rechners. So sind wir ja gerade in MEST. Wenn du dir jetzt aber ein Date-Objekt vom Januar erzeugst (oder eines dahin verschiebst) hat es EST.

aber nur, weil die zeit im januar eben MEZ zeit ist, das ist aber nicht

Der Offset ist also an das Objekt gebunden

, weil das objekt in UTC zeit vorliegt, bzw. nur ein schnöder integer ist, aber natürlich algorithmisch bestimmen kann, dass die lokale zeit im jan. nur einen offset +1 hat
EDIT: hier der algorithmus zum durchklicken falls er dich überhaupt interessiert TIDE

kann aber durch JS direkt nicht verändert werden.

doch, indem du einfach was draufaddierst, bzw. die zeit als string ausgiebst und den offset veränderst. das ist meine aussage.
weil die ausgangslage ja war, er hat einen string in utc, und will diesen als lokale zeit haben, was sinnlos ist, wei er diesen string als utc einlesen kann oder aber den lokalen offset von den stunden abziehen und als offset angeben kann. das ist sinnlos, aber möglich.
will ich nach erstellung des objektes die zeitzone ändern, kann ich entweder einfach den offset abziehen, oder gebe das objekt als string aus, hänge den offset hinten an und lese ihn neu ein.
das ist aber eigentlich kein usecase, es sei denn, ich will auf dem server ein datum in clientlokaler zeit ausgeben. dann muss man serveroffset und clientoffset verrechnen und so verfahren.

Ja und? Ich hab' nur gesagt, dass man es nicht setzen kann...

und ich sage, du kannst es

In welchem deiner Beispiele hast du die Zeitzone des Date-Objektes geändert? Und mit anderer Zeitzone meine ich nicht, dass du einfach ein paar Stunden addierst oder subtrahierst

aber nichts anderes ist es

sondern dass .getTimezoneOffset() was anderes liefert, denn das ist die Zeitzon des Objektes.

nein, das ist deine lokale

Doch - wenn du gescheit mit Zeiten rechnen willst, musst du immer nach UTC gehen. Und wenn du dann irgendwas "draufrechnest" bist du schon falsch.

Dann ist aber die UTC-Zeit falsch...

ja, weil ich keine möglichkeit habe bei der konvertierung in einen string eine gewünschte zeitzone anzugeben, muss man die UTC-Zeit anpassen. deswegen sagte ich ja, nur für die ausgabe. das hat aber nichts mit einem offset zu tun den ich nicht setzen am date-objekt setzen kann, sondern dass ich bei der ausgabe als string nur die möglichkeit habe utc oder lokal.

Äh... du wiedersprichst dir selbst. Wenn du einen Offset "draufrechnest" hast du eben inter nicht mehr das gleiche...

ich sagte utc=utc minus 2h plus 2h offset das ist eben das gleiche.

Den Offset eines Date-Objektes kann man mit .setTimezoneOffset() auslesen, aber man kann den Offset eines Date-Objektes für eine andere Ausgabe von z.B. .getHour() nicht ändern.
Das war mein Statement.

ob du nun über setTimezoneOffset() den offset und damit die utc-zeit änderst, oder diesen offset von den stunden abziehst und damit die utc-zeit änderst macht keinen unterschied.
worauf du vermutlich hinauswillst ist, dass es keine .getHourForOffset() funktion gibt, die dir das anlegen einer tmp.variable erspaart um das eigentliche objekt nicht zu verändern, ja das ist so.

Aber wie ich sehe, ist das hier wieder so eine komplett unproduktive Diskussion... meinen Punkt hab' ich ja schon in #5 klar gemacht: es gibt .getTimezoneOffset() aber nicht .setTimezoneOffset().

doch, selbst wenn du nicht über parse gehen willst und eine erneute zuweisung ist das addieren des offsets was setTimezoneOffset machen würde nichts anderes als das abziehen des offsets von den stunden.

4+d2.getTimezoneOffset()=124 nicht 21600s - JS kennt keine Einheiten (und oben hast du die Einheiten auch nicht dazugeschrieben)! Wenn du was schreibst, schreibe es gescheit!

das war kein js, sondern pseudokode im kommentar, und ich glaube du bist nicht so dämlich das nicht verstanden zu haben, sondern suchst wieder mal stunk