Parse-DateTime-mit Zeit-zone von der form PST/CEST/UTC/etc

Ich versuche zu analysieren, eine internationale datetime-string ähnlich:

24-okt-08 21:09:06 CEST

Bisher habe ich so etwas wie:

CultureInfo culture = CultureInfo.CreateSpecificCulture("nl-BE");
DateTime dt = DateTime.ParseExact("24-okt-08 21:09:06 CEST",
    "dd-MMM-yy HH:mm:ss ...", culture);

Das problem ist, was sollte ich für den '...' im format-string? Blick auf die Benutzerdefinierte Formatzeichenfolge für Datum und Uhrzeit MSDN Seite scheint nicht zu Liste ein format-string für die Analyse von Zeitzonen im PST/CEST/GMT/UTC form.

Für die Aufzeichnung, Zeit zone Abkürzungen wie EST, PST, CST sind nicht standardisiert und sind manchmal mehrdeutig (z.B. CST kann bedeuten, dass beide US-Central Standard Time-GMT-6 und China Standard Time (GMT+8).
und "Cuba Standard Time" Karibik UTC -5 und "Central Standard Time" Mittelamerika UTC - 6 Stunden. timeanddate.com/library/abbreviations/timezones

InformationsquelleAutor thelsdj | 2008-10-28

.net c#datetime parsing timezone

32

AFAIK die Zeit zone Abkürzungen werden nicht erkannt. Allerdings, wenn Sie ersetzen die Abkürzung durch die Zeitzonen-offset, es wird in Ordnung sein. E. g.:
```
DateTime dt1 = DateTime.ParseExact("24-okt-08 21:09:06 CEST".Replace("CEST", "+2"), "dd-MMM-yy HH:mm:ss z", culture);
DateTime dt2 = DateTime.ParseExact("24-okt-08 21:09:06 CEST".Replace("CEST", "+02"), "dd-MMM-yy HH:mm:ss zz", culture);
DateTime dt3 = DateTime.ParseExact("24-okt-08 21:09:06 CEST".Replace("CEST", "+02:00"), "dd-MMM-yy HH:mm:ss zzz", culture);
```
Wird dieser Griff Sommerzeit?
Nein, es ist nicht möglich, da der offset angegeben wird hier manuell.
Es wird, vorausgesetzt, Sie haben eine Replace-Aufruf für alle, die Zeitzonen, die Sie möglicherweise erhalten und die Quelle, Datum, verwendet die korrekte Zeitzone (z.B. nicht verwenden, EST, wenn Sie meine EDT)
also warte.. es tut behandeln Sommerzeit oder nicht?
Angesichts CEST (central european summer time) und MEZ (Mitteleuropäische [winter -] Zeit) sind nicht die gleichen, dann ja. Aber ein Aufruf zu ersetzen, ist riskant, da Sie nicht wissen, ob MESZ/MEZ Eintritt in den Datum-string für Kultur-X.

InformationsquelleAutor Panos
22

Die kurze Antwort ist, Sie kann es nicht.

Hier ist der Grund, warum

Gibt es eine definitive Datenbank der Welt, Zeitzonen, Sie können es von der IANA hier.

Das problem ist, die 3 oder 4 Buchstaben-Abkürzungen haben eine viele-zu-eine Verknüpfung mit der IANA Zeitzonen. Zum Beispiel "AMT" bedeutet, verschiedene Dinge, je nach Ihrer Kultur, was Teil der Welt Sie sich befinden, und der Kontext Ihrer Anwendung.
```
AMT "Armenia Time" Asia          UTC + 4 hours 
AMT "Amazon Time"  South America UTC - 4 hours 
```
Wenn Sie wirklich wollen, zu begegnen, schlage ich vor, Noda Zeit repräsentieren Ihr Instances. Sie müssen code schreiben, der zum konvertieren der Abkürzungen zu einem standard IANA Zeitzone.

Wir können das nicht für Sie, es hängt vom Kontext Ihrer Anwendung.

Weiteres gutes Beispiel ist "CST".
```
CST "China Standard Time"   Asia            UTC + 8 hours 
CST "Central Standard Time" Central America UTC - 6 hours 
CST "Cuba Standard Time"    Caribbean       UTC - 5 hours 
CST "Central Standard Time" North America   UTC - 6 hours 
```
Technisch ist das noch machbar, da können Sie ein CultureInfo Objekt der parser keine Verwechslungen Ihren Kontext.
ja, wenn Sie wollten, dass die Abkürzungen in diesem Fall in einer vergangen Kultur, die Sie arbeiten könnte sich die Zuordnungen.
Nein, Sie konnte es nicht. Kultur-info wird Ihnen sagen, Dinge über die Sprache des Benutzers und kulturellen Präferenzen. Es wird Ihnen sagen, nichts über die Zeitzone des Benutzers. Meine Kultur sein könnte en-US auch wenn ich zu Besuch bin Japan.
aber wenn Ihre Kultur ist en-US könnten wir folgern, dass CST gemeint "Central Standard Time" North America UTC -6 Sie unabhängig von Ihrer Zeitzone, auch wenn es UTC-5. Natürlich, was angemessen ist für eine Anwendung ungeeignet sein für den anderen. Im abstrakten, Sie können nicht sagen, wie meine Antwort-Staaten. Mit genügend Kontext, ein Teil von denen wäre, die er der Kultur, wir sagen könnte.
"en-US" soll bedeuten, "English as spoken in the United States". In anderen Worten, UNS ist bezogen auf Dialekt, nicht die Lage. Warum ist es richtig zu folgern, Central Standard Time von CST nur, weil ich Englisch sprechen in der Weise, dass die Amerikaner tun? Sicher, die Amerikaner sagen "CST", aber wir könnten auch sagen, dass bezogen auf China - vor allem, wenn wir gerade in China. 🙂

InformationsquelleAutor Jodrell

Wörterbuch der Abkürzungen, wenn Sie sich entscheiden, zu gehen, die suchen&ersetzen Sie die route (die ich habe).

Dictionary<string, string> _timeZones = new Dictionary<string, string>() {
            {"ACDT", "+1030"},
            {"ACST", "+0930"},
            {"ADT", "-0300"},
            {"AEDT", "+1100"},
            {"AEST", "+1000"},
            {"AHDT", "-0900"},
            {"AHST", "-1000"},
            {"AST", "-0400"},
            {"AT", "-0200"},
            {"AWDT", "+0900"},
            {"AWST", "+0800"},
            {"BAT", "+0300"},
            {"BDST", "+0200"},
            {"BET", "-1100"},
            {"BST", "-0300"},
            {"BT", "+0300"},
            {"BZT2", "-0300"},
            {"CADT", "+1030"},
            {"CAST", "+0930"},
            {"CAT", "-1000"},
            {"CCT", "+0800"},
            {"CDT", "-0500"},
            {"CED", "+0200"},
            {"CET", "+0100"},
            {"CEST", "+0200"},
            {"CST", "-0600"},
            {"EAST", "+1000"},
            {"EDT", "-0400"},
            {"EED", "+0300"},
            {"EET", "+0200"},
            {"EEST", "+0300"},
            {"EST", "-0500"},
            {"FST", "+0200"},
            {"FWT", "+0100"},
            {"GMT", "GMT"},
            {"GST", "+1000"},
            {"HDT", "-0900"},
            {"HST", "-1000"},
            {"IDLE", "+1200"},
            {"IDLW", "-1200"},
            {"IST", "+0530"},
            {"IT", "+0330"},
            {"JST", "+0900"},
            {"JT", "+0700"},
            {"MDT", "-0600"},
            {"MED", "+0200"},
            {"MET", "+0100"},
            {"MEST", "+0200"},
            {"MEWT", "+0100"},
            {"MST", "-0700"},
            {"MT", "+0800"},
            {"NDT", "-0230"},
            {"NFT", "-0330"},
            {"NT", "-1100"},
            {"NST", "+0630"},
            {"NZ", "+1100"},
            {"NZST", "+1200"},
            {"NZDT", "+1300"},
            {"NZT", "+1200"},
            {"PDT", "-0700"},
            {"PST", "-0800"},
            {"ROK", "+0900"},
            {"SAD", "+1000"},
            {"SAST", "+0900"},
            {"SAT", "+0900"},
            {"SDT", "+1000"},
            {"SST", "+0200"},
            {"SWT", "+0100"},
            {"USZ3", "+0400"},
            {"USZ4", "+0500"},
            {"USZ5", "+0600"},
            {"USZ6", "+0700"},
            {"UT", "-0000"},
            {"UTC", "-0000"},
            {"UZ10", "+1100"},
            {"WAT", "-0100"},
            {"WET", "-0000"},
            {"WST", "+0800"},
            {"YDT", "-0800"},
            {"YST", "-0900"},
            {"ZP4", "+0400"},
            {"ZP5", "+0500"},
            {"ZP6", "+0600"}
        };

Sorry, aber dieser Ansatz ist unzuverlässig. Alle hartcodierten Liste von Abkürzungen zur Aufrechnung ist rechthaberisch mit Rücksicht auf Zweideutigkeiten, und ist nur eine Momentaufnahme in der Zeit.
Natürlich ist es das. Es ist genauso (un)zuverlässig wie mit diesen nicht-standardisierten Zeitzonen in den ersten Platz. Meine Antwort ist nur die Sicherung der akzeptierten Antworten. Denken Sie daran, um nach unten zu Stimmen, dass, wie gut.
Manche Menschen (ich würde sogar noch weiter gehen und sagen, die meisten) eigentlich nur Daten empfangen relevant, um eine einzige Kultur. Dieser Ansatz, inperfect, genügt.
Das ist unzuverlässig, selbst für eine einzelne Kultur. Russland verändert Sommerzeit-Regeln viele Male in den letzten 4 Jahren. Zuordnung der Kürzel zu einer IANA-oder Windows-tz-Namen und nach den aktuellen Regeln ist weitaus zuverlässiger

InformationsquelleAutor Jussi Palo

3

Habe ich zwei Antworten, weil ich bin mir nicht ganz sicher, was Ihr bittet.

1) ich sehe sind Sie mit CultureInfo, so dass, wenn Sie nur wollen, um format
das Datum und die Zeit werden kulturspezifische, würde ich trennen Sie das Datum/Zeit und Zeitzone, gelten Kultur-Methode für Datum/Zeit und fügen Sie die Zeitzone. Wenn "CEST" ist für die unterschiedlichen Kulturen, die Sie haben, um es zu ändern, indem der Liste der Optionen (vielleicht in einer case-Anweisung).

2) Wenn Sie möchten, dass Datum/Uhrzeit umgewandelt werden, um zu einer anderen Zeitzone, können Sie nicht verwenden, CultureInfo,

Schlage ich vor zu Lesen:
http://msdn.microsoft.com/en-us/library/ms973825.aspx

Können Sie auch die .net framework 3.5 TimeZoneInfo-Klasse (eine andere Zeitzone), um Ihr Leben leichter machen.

http://msdn.microsoft.com/en-us/library/system.timezoneinfo.aspx

InformationsquelleAutor hmak

Dies ist, wie:

Holen Sie sich die Zeichenfolge (Voraussetzung: format: ddd, dd MMM yyyy HH:mm:ss zzz)
Das Letzte Leerzeichen
Entfernen Sie zzz aus der Zeichenfolge, sondern speichern Sie den Wert von zzz
Lookup offset für zzz
Add offset auf string

string dateString = reader.ReadContentAsString();
int timeZonePos = dateString.LastIndexOf(' ') + 1;
string tz = dateString.Substring(timeZonePos);
dateString = dateString.Substring(0, dateString.Length - tz.Length );
dateString += s_timeZoneOffsets[tz];

//https://msdn.microsoft.com/en-us/library/w2sa9yss(v=vs.110).aspx
//string es = reader.ReadElementString("pubDate");
this.m_value = System.DateTime.ParseExact(dateString, "ddd, dd MMM yyyy HH:mm zzz", System.Globalization.CultureInfo.InvariantCulture);

mit

private static System.Collections.Generic.Dictionary<string, string> s_timeZoneOffsets =
    new System.Collections.Generic.Dictionary<string, string>() {
    {"ACDT", "+10:30"},
    {"ACST", "+09:30"},
    {"ADT", "-03:00"},
    {"AEDT", "+11:00"},
    {"AEST", "+10:00"},
    {"AHDT", "-09:00"},
    {"AHST", "-10:00"},
    {"AST", "-04:00"},
    {"AT", "-02:00"},
    {"AWDT", "+09:00"},
    {"AWST", "+08:00"},
    {"BAT", "+03:00"},
    {"BDST", "+02:00"},
    {"BET", "-11:00"},
    {"BST", "-03:00"},
    {"BT", "+03:00"},
    {"BZT2", "-03:00"},
    {"CADT", "+10:30"},
    {"CAST", "+09:30"},
    {"CAT", "-10:00"},
    {"CCT", "+08:00"},
    {"CDT", "-05:00"},
    {"CED", "+02:00"},
    {"CET", "+01:00"},
    {"CEST", "+02:00"},
    {"CST", "-06:00"},
    {"EAST", "+10:00"},
    {"EDT", "-04:00"},
    {"EED", "+03:00"},
    {"EET", "+02:00"},
    {"EEST", "+03:00"},
    {"EST", "-05:00"},
    {"FST", "+02:00"},
    {"FWT", "+01:00"},
    {"GMT", "+00:00"},
    {"GST", "+10:00"},
    {"HDT", "-09:00"},
    {"HST", "-10:00"},
    {"IDLE", "+12:00"},
    {"IDLW", "-12:00"},
    {"IST", "+05:30"},
    {"IT", "+03:30"},
    {"JST", "+09:00"},
    {"JT", "+07:00"},
    {"MDT", "-06:00"},
    {"MED", "+02:00"},
    {"MET", "+01:00"},
    {"MEST", "+02:00"},
    {"MEWT", "+01:00"},
    {"MST", "-07:00"},
    {"MT", "+08:00"},
    {"NDT", "-02:30"},
    {"NFT", "-03:30"},
    {"NT", "-11:00"},
    {"NST", "+06:30"},
    {"NZ", "+11:00"},
    {"NZST", "+12:00"},
    {"NZDT", "+13:00"},
    {"NZT", "+12:00"},
    {"PDT", "-07:00"},
    {"PST", "-08:00"},
    {"ROK", "+09:00"},
    {"SAD", "+10:00"},
    {"SAST", "+09:00"},
    {"SAT", "+09:00"},
    {"SDT", "+10:00"},
    {"SST", "+02:00"},
    {"SWT", "+01:00"},
    {"USZ3", "+04:00"},
    {"USZ4", "+05:00"},
    {"USZ5", "+06:00"},
    {"USZ6", "+07:00"},
    {"UT", "-00:00"},
    {"UTC", "-00:00"},
    {"UZ10", "+11:00"},
    {"WAT", "-01:00"},
    {"WET", "-00:00"},
    {"WST", "+08:00"},
    {"YDT", "-08:00"},
    {"YST", "-09:00"},
    {"ZP4", "+04:00"},
    {"ZP5", "+05:00"},
    {"ZP6", "+06:00"}
};

Danke. Ja, es waren viele schlechte Antworten.
Dies ist immer noch eine schlechte Antwort für die Gründe diskutiert, die an anderer Stelle auf dieser Seite. Sie sind hart codierten Annahmen über das, was Abkürzungen wie "AMT" oder "CST" bedeuten. Das problem ist, hat diese Frage keine gute Antwort; die codes sind nicht eindeutig und keine lookup-Tabelle können Sie definitiv. Diese Annahmen können allerdings zu lösen OP ' s problem, aber Sie wurden nicht erwähnt in der Frage.
Setzen Sie nicht "Necromancing" Erklärungen in deinen Beiträgen. Diese sind in Unordnung; SO ist keine Politik über Aktivitäten auf alte Fragen. Wenn überhaupt, ist es etwas ermutigt, weil neue Antworten entstehen, weil sich die Technologie ändert.

InformationsquelleAutor Stefan Steiger

-1

Hier ist, was ich zu tun hatte.

Erhalte ich die datetime von javascript und übergeben ihn an ASP.NET zum speichern in einer Oracle-Datenbank. Hier ist mein C# code für Ost-und zentral-Zeiten.

string datetimevalue = hidfileDateTime.Value; 

datetimevalue= datetimevalue.Replace("EDT", "EST"); 
datetimevalue = datetimevalue.Replace("CDT", "CST");
if (datetimevalue.Contains("CST"))
{
    filedt = DateTime.ParseExact(datetimevalue, "ddd MMM d HH:mm:ss CST yyyy", provider).ToUniversalTime().AddHours(1).ToLocalTime();
}
else
{
    filedt = DateTime.ParseExact(datetimevalue, "ddd MMM d HH:mm:ss EST yyyy", provider);
}

InformationsquelleAutor Deep Kumar

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.