Müssen Epoch Times in bestimmten Zeitzone lesen und dann in Benutzer Zeitzone

Question

konvertieren

Ich habe 2 Webapps, 1 davon auf Wolke ist "Master", zu denen ich Daten in der 2. Webapp "Kind" übereinstimmen muss.

Master (1. Webapp, Wolke) zeigt Datum in IST, Asien/Kolkata, die es von SQL-Maschine sitzt in EST-Zeitzone liest.

Child (2. webapp) liest seine Daten aus Elasticsearch, wo ein Java-Feeder die SQL-Daten aufnimmt und an Elasticsearch weitergibt, so wie es ist, ohne Konvertierung.

Wenn ich versuche, diese Elasticsearch Daten in meinem Webapp (Kind)

in meinem Webapp

... 
{ 
    "_index": "log_event_2016-05-05", 
    "_type": "log_event", 
    "_id": "65708004", 
    "_score": null, 
    "_source": { 
     "task_name": "kn_cvs_test", 
     "task_start_time": "2016-05-05T19:05:05.000-07:00", 
     "task_end_time": "2016-05-05T19:05:06.000-07:00", 
     "started_by": "Schedule \"10Minutes\"", 
     "log_datetime": 1462475106000, 
     "dw_insert_dt": "2016-05-05T16:40:54.000-07:00" 
    }, 
    "sort": [ 
     1462475106000 
    ] 
}, { 
    "_index": "log_event_2016-05-05", 
    "_type": "log_event", 
    "_id": "65708005", 
    "_score": null, 
    "_source": { 
     "task_name": "kn_cvs_test", 
     "task_start_time": "2016-05-05T18:55:08.000-07:00", 
     "task_end_time": "2016-05-05T18:55:11.000-07:00", 
     "started_by": "Schedule \"10Minutes\"", 
     "log_datetime": 1462474511000, 
     "dw_insert_dt": "2016-05-05T16:40:54.000-07:00" 
    }, 
    "sort": [ 
     1462474511000 
    ] 
} 
... 

die Termine und die Wolke zu lesen nicht übereinstimmt. Bitte korrigieren Sie mich, wenn ich falsch liege. Da Sql Daten in EST speichert, "America/New_York", sollte Momentjs zuerst die data = 1462475106000 in EST lesen und dann die Benutzerzeitzone anwenden, die IST, "Asia/Kolkata" ist. Ist das richtig?

//Timestamp column in table 
//data = 1462475106000 
$scope.getMeData = function(data) { 
    var dFormat = "YYYY-MM-DD hh:mm:ss A"; 
    moment.tz.setDefault("America/New_York");  
    return moment.tz(data, "Asia/Kolkata").format(dFormat); 
} 

Hinweis: 1462475106000 ist der erste Eintrag in beide Tabelle

ich ein plunker here bin das Aufstellen. Bitte helfen Sie mir herauszufinden, was könnte schief gehen und wie kann ich Termine in beiden Webapps (Cloud als Referenz nehmen).

aktualisieren

Java Feeder führt eine SQL-Abfrage alle benötigten Spalten zu holen. Hier ist, wie log_datetime abgerufen wird. Ist das der richtige Weg zu holen?

Also nehme ich an, wenn es Daten holt Daylight Saving Information wird nicht berücksichtigt und ich verpasse diese Informationen auch. Also auf UI-Seite werde ich für isDST() überprüfen und eine +5: 00 Stunden oder +4: 00 Stunden je nachdem tun, wie Datum in SQL in America/New_York gespeichert ist. Plunker with UI fix

Answer 1

Es gibt immer nur eine Epochzeit. Es ist ein absoluter Wert.

Ein Wert, der ungefähr der Anzahl der Sekunden entspricht, die seit der Epoche verstrichen sind. Der Name einer koordinierten Weltzeit (angegeben in Sekunden (tm_sec), Minuten (tm_min), Stunden (tm_hour), Tagen seit dem 1. Januar des Jahres (tm_yday) und Kalenderjahr minus 1900 (tm_year)) steht in Beziehung zu einer Zeit dargestellt als Sekunden seit der Epoche, gemäß dem Ausdruck unten.

Refhttp://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15

Epoch Zeit wird aus der 01-01-1970 00:00:00 UTC gemessen. Das ist ein absoluter Zeitpunkt, es ist nicht relativ zur Zeitzone, da die Zeitzone UTC in der Definition der Epoche ist.

Wenn Sie eine Nummer für ein Datum wie Ihr Beispiel 1462475106000 sehen, sollte davon ausgegangen werden, dass es sich in UTC/GMT befindet. Es ist kein zeitzonenspezifischer Wert.Da die Zeit eine Unix-basierte Zahl ist, ist nach Epochendefinition die Zeit seit der Epoche verstrichen (in UTC), was sie zur absoluten Zeit macht.

(01-01-1970 00:00:00 UTC)(epoch) + 1462475106000 = Time in UTC 

Ein Datum in Zeichenfolge ist eine ganz andere Sache. Es sollte den Zeitzonen-Offset mit dem Datumsteil enthalten. Datumsteil würde als zeitzonenspezifischer Wert betrachtet werden. Durch das Hinzufügen eines Zeitzonen-Offsets würde es in UTC in einen absoluten Wert umgewandelt. Ohne Zeitzoneninformationen hat ein String-Datum keinen absoluten Wert (Zeitpunkt).

2016-05-05T18:55:08.000-07:00 = (2016-05-05T18:55:08.000) + (07:00 hrs) UTC 
or 
date + timezone offset = date - offset hrs UTC 

Datenbanken speichern keine Daten in irgendeinem Timzzone. Sie speichern den absoluten Unix-Zeitwert. Die Zeitzoneneinstellung in Datenbanken wird so eingestellt, dass die Ausgabe der Abfrage in der Zeichenfolge in diesem Zeitzonenformat angezeigt wird. Diese Einstellung gibt nur das Ausgabeformat an, nicht den Wert. Da der Wert absolut ist, ist er unabhängig von der Zeitzone.

Diese Einstellung hilft der Datenbank bei der Bestimmung der Zeitzone des Datumswertes, den ein Benutzer einfügt, wenn er den Offset der Zeitzone verpasst. Wenn der Benutzer versucht, eine Zeichenfolge in die Datumsspalte ohne die Zeitzonen-Datenbank einzufügen, wird versucht, die Zeichenfolge auf die Datenbank-Zeitzoneneinstellung zu setzen.

Also 1462475106000 ist ein Wert in UTC, wie es Unix Zeit ist. Es ist nicht in EST.

Wenn Sie das Datum in EST benötigen, verwenden Sie das Datum im Zeichenfolgenformat nicht im Zahlenformat, da das Zahlenformat immer UTC ist.

moment.tz.setDefault("America/New_York");//sets the output date format in EST 

Above-Code wird keine Auswirkung, da es nun überschrieben werden von moment.tz(data, "Asia/Kolkata")

den ersten Eintrag in der ersten Screenshot berücksichtigen.

2016-05-06T04:35:06.000+5:30 (IST) = 2016-05-05T11:05:06.000-00:00 (UTC) 

es mit dem zweiten Bildschirm Vergleich, da die Zeitdifferenz zwischen den zwei 4 Stunden beträgt, sollte eine zweite in +01:30 Zeitzone sein, wenn sie beide die gleichen Werte in der absoluten Zeit sind.

2016-05-06T12:35:06.000+1:30 = 2016-05-05T11:05:06.000-00:00 (UTC) 

jedoch in dem Kind ist der Wert

2016-05-05T19:05:06.000-07:00 = 2016-05-06T02:05:06.000-00:00 (UTC) 

Was nicht der gleiche Wert wie beide oben ist. Interessanter Fakt ist, dass nur Datum Teil in dem Kind 2016-05-05T19:05:06.000, wenn IST Offset +05:30 Offset würde der Datum Teil im zweiten Screenshot werden.

2016-05-06T12:35:06.00 - 2016-05-05T19:05:06.000 = 5:30 (IST offset) 

dass Verlassen Sie Ihr Java-Feeder-Code ElasticSearch beiseite ist wahrscheinlich hier Schuldige.

Es wird nicht die richtige Date-Timezone-Kombination für ElasticSearch geschrieben. Verwenden Sie die überladene Methode getDate() getDate(int columnIndex, Calendar cal) in JDBC.

Manchmal JDBC-Treiber vermisst Zeitzone Informationen, wodurch das Datum in Standarddatenbank Zeitzone gespeichert wird, mit Calendar würde das heilen.

Das gleiche gilt für das Schreiben von Daten als auch.

void setDate(int parameterIndex, Date x, Calendar cal) throws SQLException

Answer 2

Sie müssen nur Daten konvertieren von Amerika/New York nach Asien/Kolkata (Asien/Kalkutta)?

var newYork = moment.tz("date-from-database", "America/New_York"); 
var calcutta = newYork.clone().tz("Asia/Calcutta"); 

Beispiel

var newYork = moment.tz("2016-05-06 12:00:00", "America/New_York"); 
var losAngeles = newYork.clone().tz("America/Los_Angeles"); 
var london  = newYork.clone().tz("Europe/London"); 
var Kolkata  = newYork.clone().tz("Asia/Kolkata"); 
var dFormat = "YYYY-MM-DD hh:mm:ss A"; 
console.log(newYork.format(dFormat),losAngeles.format(dFormat),london.format(dFormat),Kolkata.format(dFormat)); 

Fiddle