Benutzer mit den meisten Antworten
Umgang mit Datum / Uhrzeit - Speichern - Filtern - Abrufen

Frage
-
Hallo,
ich muss eine Anwendung entwickeln, bei der über eine Webseite (ASP.NET) Datum und Uhrzeit in einer MSSQL Express DB gespeichert werden sollen mit entsprechenden Daten (ID, StartDate, StartTime, EndDate, EndTime, RecurrencyString, Description). Das Ganze soll dann über Desktopanwendungen unter Zuhilfenahme von Webservice abgerufen werden. Dies kann jedoch aus unterschiedlichen Kulturkreisen abgerufen werden - online wie auch Desktopanwendung mit Webservice.
Macht es Sinn, das Datum und die Uhrzeit als string abzulegen und in der entsprechenden Anwendung zu parsen? Kann man in Der DB dann gezielt nach Datum/Uhrzeit suchen? Oder was habt Ihr für Erfahrungen? Was ist der universellste Weg? ich bin Dankbar für jede Hilfe und Tipps.
Schönes Wochenende noch
Claudia
- Typ geändert Robert BreitenhoferModerator Mittwoch, 2. Mai 2012 08:09 Frage
Antworten
-
Hallo Claudia,
Pfui, ein Datum als String. Sowas macht man doch nicht :)
Im Ernst. Genau das solltest Du natürlich nicht machen, wenn das Datum in verschiedenen Ländern mit unterschiedlichen Formaten benötigt wird. Über die Webservices wird das Datum in der Regel (wenn Du nicht explizit etwas anderes machst) in einem universellen Format übertragen. Arbeite für die Datenbankabfragen ausschließlich mit Parametern, dann hast Du auch an dieser Stelle keine Probleme.
Die Ausgabe auf dem jeweiligen Client hängt von dessen Ländereinstellungen und der Culture deiner Anwendung ab. Aber auch hier arbeitet man immer mit einem Datum, nie mit einem irgendwie verkorksten String (außer zur Anzeige selbst, da kann man das schon machen, wenn man eine bestimmte Ausgabe benötigt)
Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET
http://www.asp-solutions.de/ - Consulting, Development
http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community- Als Antwort markiert Robert BreitenhoferModerator Mittwoch, 2. Mai 2012 08:10
-
Hallo Claudia,
Für deine Anwendung würde ich folgende Technologien empfehlen:
Server: IIS, ASP.NET, WCF-Dienst, SQL Server
Client : WF/WPF / Internet Browser, WCF-ClientAls Datums-Typ würde ich .NET-seitig DateTimeOffset empfehlen (evtl. in der Nullable-Variante) und SQL Server-seitig DATETIMEOFFSET (auch in Express-Versionen ab v.2008 verfügbar). Der ab .NET 3.5 verfügbare Datentyp DateTimeOffset ist ein DateTime, dem man einen Offset-Teil hinzugefügt hat. Dies wird deutlich, wenn man sich ansieht, wie die Serialisierung "auf dem Draht" aussieht:
<DateOffset xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns:x="http://www.w3.org/2001/XMLSchema"> <DateTime i:type="x:dateTime" xmlns="">2012-04-22 17:36:00.0000000 +02:00</DateTime> <OffsetMinutes i:type="x:short" xmlns="">120</OffsetMinutes> </DateOffset>
Damit ist deine Anwendung schon mal auf der sicheren Seite. Ich möchte dich aber warnen, dass die Datums-Probleme viel komplexer sind, als man gemeinhin meint. Selbst das neue DateTimeOffset hat Stolperfallen, z.B. weiß man sehr wohl das UTC-Offset, aber kann den Datums-Wert nicht automatisch zu einer bestimmten Zeitzone mappen. Dies könnte problematisch werden, wenn man z.B. die Sommerzeit in Betracht ziehen muss. In diesem Fall müßte man sich TimeZoneInfo ansehen (s. Link unten).
Die Auswahl von DATETIMEOFFSET auf dem SQL Server wirkt sich auf das Tabellen-Schema dahingehend aus, dass die redundante, separate Speicherung von Datum *und* Zeit entfällt. Mit anderen Worten wirst Du nicht mehr StartDate und StartTime benötigen, sondern nur noch StartDateTime. Dies wirkt sich positiv auf Abfragen aus, da man nun Zeitpunkte global miteinenader vergleichen kann. Etwas Umdenken bei der Entwicklung ist aber auch hier notwendig, denn eine Abfrage wie:
SELECT StartDateTime, EndDateTime, RecurrencyString, Description
FROM Appointments
WHERE (StartDateTime = '2012-04-22 15:36:00')könnte berechtigterweise folgendes Resultat bringen:
siehe auch: Auswählen zwischen "DateTime", "DateTimeOffset" und "TimeZoneInfo"
http://msdn.microsoft.com/de-de/library/bb384267.aspxGruß
Marcel- Als Antwort markiert Robert BreitenhoferModerator Mittwoch, 2. Mai 2012 08:10
Alle Antworten
-
Hallo Claudia,
Pfui, ein Datum als String. Sowas macht man doch nicht :)
Im Ernst. Genau das solltest Du natürlich nicht machen, wenn das Datum in verschiedenen Ländern mit unterschiedlichen Formaten benötigt wird. Über die Webservices wird das Datum in der Regel (wenn Du nicht explizit etwas anderes machst) in einem universellen Format übertragen. Arbeite für die Datenbankabfragen ausschließlich mit Parametern, dann hast Du auch an dieser Stelle keine Probleme.
Die Ausgabe auf dem jeweiligen Client hängt von dessen Ländereinstellungen und der Culture deiner Anwendung ab. Aber auch hier arbeitet man immer mit einem Datum, nie mit einem irgendwie verkorksten String (außer zur Anzeige selbst, da kann man das schon machen, wenn man eine bestimmte Ausgabe benötigt)
Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET
http://www.asp-solutions.de/ - Consulting, Development
http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community- Als Antwort markiert Robert BreitenhoferModerator Mittwoch, 2. Mai 2012 08:10
-
Hallo Claudia,
Für deine Anwendung würde ich folgende Technologien empfehlen:
Server: IIS, ASP.NET, WCF-Dienst, SQL Server
Client : WF/WPF / Internet Browser, WCF-ClientAls Datums-Typ würde ich .NET-seitig DateTimeOffset empfehlen (evtl. in der Nullable-Variante) und SQL Server-seitig DATETIMEOFFSET (auch in Express-Versionen ab v.2008 verfügbar). Der ab .NET 3.5 verfügbare Datentyp DateTimeOffset ist ein DateTime, dem man einen Offset-Teil hinzugefügt hat. Dies wird deutlich, wenn man sich ansieht, wie die Serialisierung "auf dem Draht" aussieht:
<DateOffset xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns:x="http://www.w3.org/2001/XMLSchema"> <DateTime i:type="x:dateTime" xmlns="">2012-04-22 17:36:00.0000000 +02:00</DateTime> <OffsetMinutes i:type="x:short" xmlns="">120</OffsetMinutes> </DateOffset>
Damit ist deine Anwendung schon mal auf der sicheren Seite. Ich möchte dich aber warnen, dass die Datums-Probleme viel komplexer sind, als man gemeinhin meint. Selbst das neue DateTimeOffset hat Stolperfallen, z.B. weiß man sehr wohl das UTC-Offset, aber kann den Datums-Wert nicht automatisch zu einer bestimmten Zeitzone mappen. Dies könnte problematisch werden, wenn man z.B. die Sommerzeit in Betracht ziehen muss. In diesem Fall müßte man sich TimeZoneInfo ansehen (s. Link unten).
Die Auswahl von DATETIMEOFFSET auf dem SQL Server wirkt sich auf das Tabellen-Schema dahingehend aus, dass die redundante, separate Speicherung von Datum *und* Zeit entfällt. Mit anderen Worten wirst Du nicht mehr StartDate und StartTime benötigen, sondern nur noch StartDateTime. Dies wirkt sich positiv auf Abfragen aus, da man nun Zeitpunkte global miteinenader vergleichen kann. Etwas Umdenken bei der Entwicklung ist aber auch hier notwendig, denn eine Abfrage wie:
SELECT StartDateTime, EndDateTime, RecurrencyString, Description
FROM Appointments
WHERE (StartDateTime = '2012-04-22 15:36:00')könnte berechtigterweise folgendes Resultat bringen:
siehe auch: Auswählen zwischen "DateTime", "DateTimeOffset" und "TimeZoneInfo"
http://msdn.microsoft.com/de-de/library/bb384267.aspxGruß
Marcel- Als Antwort markiert Robert BreitenhoferModerator Mittwoch, 2. Mai 2012 08:10
-
Hallo Claudia Salzwedel,
Ich gehe davon aus, dass die Antworten Dir weitergeholfen haben.
Solltest Du noch "Rückfragen" dazu haben, so gib uns bitte Bescheid.Grüße,
RobertRobert Breitenhofer, MICROSOFT
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „Entwickler helfen Entwickler“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.