Ich hab folgendes Phänomen festgestellt.

Angenommen ich erstelle in einer Webseite per Javascript ein neues Datum anhand einer Benutzereingabe

var myDate = new Date(year,month,day);

[/PHP]

dann erhalte ich zum Beispiel folgendes Object

[PHP]
Sat Mar 1 00:00:00 UTC+0100 2008

Was für meine Zeitzone ja korrekt ist.

Wenn ich dieses nun per Ajax an eine WebMethod übertrage

PageMethod.Foo(myDate);


bzw.

[WebMethod(true)]

public static void Foo(DateTime myDate)

[/PHP]

dann erhalte ich Serverseitig in myDate {29.02.2008 23:00:00}

Es wird also automatisch die Stunde Zeitverschiebung abgezogen, so dass ich ein ganz anderes Datum erhalte.

Die Frage ist wieso bzw. wie bekomme ich wieder das auf der Seite eingegebene Datum? Der Typ des C# DateTime Objects ist auch UTC, so das die Zeitangabe schon stimmt, aber das bringt mich ja nicht weiter weil ich als Datum den 1.3 und nicht den 29.2 brauche. Denn theoretisch müsste der Typ des DateTime Objekts ja nicht UTC sondern UTC+1 sein, aber den gibt es ja nicht.

Ich könnte jetzt natürlich ToLocalTime auf dem Server aufrufen um das wieder umzurechnen, aber das funktioniert ja auch nur wenn sich Server und Client in der selben Zeitzone befinden und außerdem müsste man dann ja jedes Datumsobjekt was zum Server übertragen wird manuell anpacken.

Da muss es doch irgendeinen automatismus geben... :confused:

Hi Guybrush,

haben den sowohl Client als auch server die selbe zeitzone?

Einen Ähnlichen effekt hatten wir bei uns auch schon...

versuch mal ob du die Zeitzone des Client mit übergeben...

OT:

hast du eine gute Informationsquelle für Ajax + C# .Net ???

Gerade im bezug auf

Was für meine Zeitzone ja korrekt ist.

Wenn ich dieses nun per Ajax an eine WebMethod übertrage

PHP-Code:

PageMethod.Foo(myDate);

bzw.

[WebMethod(true)]

public static void Foo(DateTime myDate)

OT ENde

Grüße

Wolf

Wenn die relative Zeitzone zwischen Client und Server ignoriert werden soll, würde ich einfach Tag, Monat und Jahr als Integer an den Server übergeben und dort erst ein Date-Objekt daraus konstruieren.

Hab mir nochmal ein paar Gedanken darüber gemacht und ich glaube mittlerweile das das schon gut so ist wie es passiert.

Also der Client sendet ein lokales Datum was auf dem Server als UTC Datum behandelt wird. Das würde ja Probleme verhindern wenn verschiedene Clients aus unterschiedlichen Zeitzonen kommen. Ich denke aber trotzdem das da noch irgendwo der Wurm drin ist je nach dem wo genau das Datum erzeugt wird bzw. was damit geschieht, aber das noch genauer analysiert werden.

Prinzipiell muss es schon möglich sein das Server und Clients in unterschiedlichen Zeitzonen arbeiten...

@U[[ °LoneWolf°

Nee außer der normalen Referenz die dabei ist wüßte ich jetzt nichts...

PS:

Wenn die relative Zeitzone zwischen Client und Server ignoriert werden soll, würde ich einfach Tag, Monat und Jahr als Integer an den Server übergeben und dort erst ein Date-Objekt daraus konstruieren.

Das Problem daran ist halt das man jedes Objekt nochmal anpacken muss. Das ist vorallem sehr umständlich wenn man komplexere Objecte austauscht die mehrere Daten enthalten.