none
Umgang mit Datum / Uhrzeit - Speichern - Filtern - Abrufen RRS feed

  • 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

    Sonntag, 22. April 2012 12:20

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

    Sonntag, 22. April 2012 13:03
    Moderator
  • 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-Client

    Als 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:

    Query output

     

    siehe auch: Auswählen zwischen "DateTime", "DateTimeOffset" und "TimeZoneInfo"
    http://msdn.microsoft.com/de-de/library/bb384267.aspx

     

    Gruß
    Marcel

    Sonntag, 22. April 2012 16:15
    Moderator

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

    Sonntag, 22. April 2012 13:03
    Moderator
  • 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-Client

    Als 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:

    Query output

     

    siehe auch: Auswählen zwischen "DateTime", "DateTimeOffset" und "TimeZoneInfo"
    http://msdn.microsoft.com/de-de/library/bb384267.aspx

     

    Gruß
    Marcel

    Sonntag, 22. April 2012 16:15
    Moderator
  • 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,
    Robert


    Robert Breitenhofer, MICROSOFT  Twitter Facebook
    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.

    Mittwoch, 2. Mai 2012 08:10
    Moderator