1x mal im Halbjahr if ausführen

Amin Negm-Awad · 25. Oktober 2012, 21:11

Nein, das Programm wird nicht den einen oder anderen Tag anzeigen, weil ein Date nicht weiß, wie viele Tage das Jahr hat, wie viele Monate es hat, wie lange einzelne Monate sind, welche Zeitzone gilt. Ein Date ist eine Fließkommazahl, die Captainn Picard in dasLogbuch einträgt. Hast du den schon einmal Samstag sagen hören?

Das kann nur ein Kalender. Und da muss er sich eben entscheiden, ob er den im Datum gespeicherten Zeitpunkt als Datum in der GMT, in der UTC, in der MEZ, in der EST, … anzeigen will.

Noch einmal: Ein Date kümmert sich nicht um Zeitzonen und derlei Kleinkram, weil es für die Bestimmung eines Zeitpunktes unwichtig ist. 12.08.12 08.00 Uhr UTC ->/ist/<- derselbe Zeitpunkt wie 12.08.12 06.00 Uhr MEZ. Du kannst in beiden Kalendern Zeiten erzeugen und wirst auf isEqual: YES erhalten. Das ist alles dem Date ziemlich egal. Wenn du willst, kannst du es auch in einen thailändischen Kelander in einer kongolesischen Zeitzone anzeigen lassen. Ändert immer noch nichts am Date.

beage · 25. Oktober 2012, 21:12

Amin Negm-Awad schrieb:

Nein, das Programm wird nicht den einen oder anderen Tag anzeigen, weil ein Date nicht weiß, wie viele Tage das Jahr hat, wie viele Monate es hat, wie lange einzelne Monate sind, welche Zeitzone gilt.

Das kann nur ein Kalender. Und da muss er sich eben entscheiden, ob er den im Datum gespeicherten Zeitpunkt als Datum in der GMT, in der UTC, in der MEZ, in der EST, … anzeigen will.

Noch einmal: Ein Date kümmert sich nicht um Zeitzonen und derlei Kleinkram, weil es für die Bestimmung eines Zeitpunktes unwichtig ist. 12.08.12 08.00 Uhr UTC ->/ist/<- derselbe Zeitpunkt wie 12.08.12 06.00 Uhr MEZ. Das ist dem Date ziemlich egal. Wenn du willst, kannst du es auch in einen thailändischen Kelander in einer kongolesischen Zeitzone anzeigen lassen. Ändert immer noch nichts am Date.

jawoll

beage · 25. Oktober 2012, 21:17

beage schrieb:

Amin Negm-Awad schrieb:

Nein, das Programm wird nicht den einen oder anderen Tag anzeigen, weil ein Date nicht weiß, wie viele Tage das Jahr hat, wie viele Monate es hat, wie lange einzelne Monate sind, welche Zeitzone gilt.

Das kann nur ein Kalender. Und da muss er sich eben entscheiden, ob er den im Datum gespeicherten Zeitpunkt als Datum in der GMT, in der UTC, in der MEZ, in der EST, … anzeigen will.

Noch einmal: Ein Date kümmert sich nicht um Zeitzonen und derlei Kleinkram, weil es für die Bestimmung eines Zeitpunktes unwichtig ist. 12.08.12 08.00 Uhr UTC ->/ist/<- derselbe Zeitpunkt wie 12.08.12 06.00 Uhr MEZ. Das ist dem Date ziemlich egal. Wenn du willst, kannst du es auch in einen thailändischen Kelander in einer kongolesischen Zeitzone anzeigen lassen. Ändert immer noch nichts am Date.

jawoll

Was mir aber grad noch einfällt... Beim Vergleich von 2 NSDate macht es schon was aus. Deswegen mein o.g. Kram. Und das klappt.

Snoxxi · 25. Oktober 2012, 22:03

Amin Negm-Awad schrieb:

Nein, das Programm wird nicht den einen oder anderen Tag anzeigen, weil ein Date nicht weiß, wie viele Tage das Jahr hat, wie viele Monate es hat, wie lange einzelne Monate sind, welche Zeitzone gilt. Ein Date ist eine Fließkommazahl, die Captainn Picard in dasLogbuch einträgt. Hast du den schon einmal Samstag sagen hören?

Amin Negm-Awad schrieb:

Das kann nur ein Kalender. Und da muss er sich eben entscheiden, ob er den im Datum gespeicherten Zeitpunkt als Datum in der GMT, in der UTC, in der MEZ, in der EST, … anzeigen will.

Amin Negm-Awad schrieb:

Noch einmal: Ein Date kümmert sich nicht um Zeitzonen und derlei Kleinkram, weil es für die Bestimmung eines Zeitpunktes unwichtig ist. 12.08.12 08.00 Uhr UTC ->/ist/<- derselbe Zeitpunkt wie 12.08.12 06.00 Uhr MEZ. Du kannst in beiden Kalendern Zeiten erzeugen und wirst auf isEqual: YES erhalten. Das ist alles dem Date ziemlich egal. Wenn du willst, kannst du es auch in einen thailändischen Kelander in einer kongolesischen Zeitzone anzeigen lassen. Ändert immer noch nichts am Date.

So wie ich das kenne sind die in NSDate abgelegten Float Werte immer auf GMT bezogen, dass dir da was anderes in der GUI Angezeigt wird oder von componentsForDate zurückgeliefert wird, dass liegt dann am verwendeten Kalender und an der darin angenommen Zeitzone. Ob man aber in Berlin den 1.1.2012 00:00:00 unter Verwendung der MEZ eingibt oder in London 31.12.2011 23:00:00 ist dabei doch egal. In NSDate sollte exakt der gleiche Wert stehen. Wenn Du jetzt das NSDate persistent machst und durch die Welt reist, dann wird sich das in der GUI angezeigte Datum und die via components:FromDate: ermittelten Werte an die lokale Zeitzone anpassen sofern das System es tut.

Hier mal im Code:

Quellcode

int main(int argc, const char * argv[])
{
@autoreleasepool {
const NSUInteger dateComps = NSDayCalendarUnit | NSYearCalendarUnit | NSMonthCalendarUnit;
NSDate * now = [NSDate date];
NSCalendar * cal = [NSCalendar autoupdatingCurrentCalendar];
NSLog(@"Jetzt ist es in London: %@", now);
NSDate * begin = now;
// Die Uhrzeit ignorieren
NSDateComponents * comps = [cal components:dateComps
fromDate:begin];
NSLog(@"Verzinsung beginnt am: %lu.%lu.%lu", [comps day], [comps month], [comps year]);
begin = [cal dateFromComponents:comps];
NSLog(@"Zu Beginn des Tages war es in London: %@", begin);
// beginn in einer Datei speichern
NSDate * datumInEinerDatei = begin;
// Ab nach England.
NSLog(@"Ab nach London!");
[cal setTimeZone:[NSTimeZone timeZoneWithAbbreviation:@"GMT"]];
// beginn aus der Datei lesen
begin = datumInEinerDatei;
// Die Uhrzeit ignorieren
comps = [cal components:dateComps
fromDate:begin];
NSLog(@"Verzinsung beginnt am: %lu.%lu.%lu", [comps day], [comps month], [comps year]);
begin = [cal dateFromComponents:comps];
NSLog(@"Zu Beginn des Tages war es in London: %@", begin);
}
return 0;
}

Alles anzeigen

Ausgabe:

2012-10-25 21:59:34.710 DateExample[948:303] Jetzt ist es in London: 2012-10-25 19:59:34 +0000
2012-10-25 21:59:34.711 DateExample[948:303] Verzinsung beginnt am: 25.10.2012
2012-10-25 21:59:34.711 DateExample[948:303] Zu Beginn des Tages war es in London: 2012-10-24 22:00:00 +0000
2012-10-25 21:59:34.711 DateExample[948:303] Ab nach London!
2012-10-25 21:59:34.712 DateExample[948:303] Verzinsung beginnt am: 24.10.2012
2012-10-25 21:59:34.712 DateExample[948:303] Zu Beginn des Tages war es in London: 2012-10-24 00:00:00 +0000

Und siehe da, das Datum hat sich wie erwartet um einen Tag verschoben.

Und ja, mir ist klar, dass ein NSDate KEINE Zeitzone kennt.

beage · 25. Oktober 2012, 22:10

genau das ist doch aber der Punkt! Dein [NSDate date]! Ich setze das aber von Hand!

Snoxxi · 25. Oktober 2012, 22:19

beage schrieb:

genau das ist doch aber der Punkt! Dein [NSDate date]! Ich setze das aber von Hand!

Das Problem ist nicht das [NSDate date], sondern ein evtl. speichern und laden der Daten in einer Datei. Wobei bei automatischer Anpassung der Zeitzone aber sogar Probleme im laufendem Programm auftreten könnten, denn dann ist es denkbar, das bei Wechsel der Zeitzone deine Berechnungen durcheinander kommen, weil ein neue erzeugter NSCalendar dann u.U. auch die neue Zeitzone hat. Ich erinnere mich da dunkel an Probleme eines US Flugkörpers beim überfliegen der Datumsgrenze.

Dem NSDate ist es wie Amin schon gesagt hat vollkommen egal ob Du das per Hand setzt oder per date, dass kennt ja keine Zeitzone. Wenn Du es per Hand setzt, dann wird die aktuelle Zeitzone des aktuellen Kalenders genutzt um aus der GUI Darstellung ein NSDate umzurechnen und das NSDate bezieht sich letztlich auf GMT.

Du kannst am Anfang ja einfach mal folgendes machen:

Quellcode

NSDateComponents * userComps = [[NSDateComponents alloc] init];
[userComps setYear:2012];
[userComps setMonth:1];
[userComps setDay:1];
[userComps setHour:8];
[userComps setMinute:42];
[userComps setSecond:13];
NSCalendar * cal = [NSCalendar autoupdatingCurrentCalendar];
NSDate * now = [cal dateFromComponents:userComps];

Ausgabe ist:

2012-10-25 22:26:39.760 DateExample[1040:303] Jetzt ist es in London: 2012-01-01 07:42:13 +0000
2012-10-25 22:26:39.760 DateExample[1040:303] Verzinsung beginnt am: 1.1.2012
2012-10-25 22:26:39.761 DateExample[1040:303] Zu Beginn des Tages war es in London: 2011-12-31 23:00:00 +0000
2012-10-25 22:26:39.761 DateExample[1040:303] Ab nach London!
2012-10-25 22:26:39.761 DateExample[1040:303] Verzinsung beginnt am: 31.12.2011
2012-10-25 22:26:39.762 DateExample[1040:303] Zu Beginn des Tages war es in London: 2011-12-31 00:00:00 +0000

beage · 25. Oktober 2012, 22:29

ich hab doch aber schon weiter oben geschrieben, dass ich datum und uhrzeit von hand setze, dann ist die zeitzone doch völlig egal! der 1.1.2012 ist in Deutschland auch der 1.1.2012 in HongKong! Der sitzt fest lt. dem Eingabefeld und wird dann auf 00:00:00 Uhr gesetzt! Die Uhrzeit und Zeitzone ist hier wurscht. Wenn der User in HonKong das Programm startet un in das Eingabefeld "Start" den 1.1.2012 eingibt, dann setze ich die Uhrzeit im Programm auf 00 Uhr. In der Variable NSDate steht dann 01.01.2012 00:00:00 und das werte ich auch aus für die Berechnung, nicht mehr und nicht weniger!

Snoxxi · 25. Oktober 2012, 22:43

Nein, das NSDate welches Du vom NSDatePicker geliefert bekommst bezieht sich auf GMT und nicht auf die lokale Zeit. Deshalb ist das NSDate in London und Berlin bei gleicher Eingabe unterschiedlich.

beage · 25. Oktober 2012, 22:44

Ich setze es aber um! Ich gebs auf!

Amin Negm-Awad · 25. Oktober 2012, 22:46

Snoxxi schrieb:

Amin Negm-Awad schrieb:

Nein, das Programm wird nicht den einen oder anderen Tag anzeigen, weil ein Date nicht weiß, wie viele Tage das Jahr hat, wie viele Monate es hat, wie lange einzelne Monate sind, welche Zeitzone gilt. Ein Date ist eine Fließkommazahl, die Captainn Picard in dasLogbuch einträgt. Hast du den schon einmal Samstag sagen hören?

Amin Negm-Awad schrieb:

Das kann nur ein Kalender. Und da muss er sich eben entscheiden, ob er den im Datum gespeicherten Zeitpunkt als Datum in der GMT, in der UTC, in der MEZ, in der EST, … anzeigen will.

Amin Negm-Awad schrieb:

Noch einmal: Ein Date kümmert sich nicht um Zeitzonen und derlei Kleinkram, weil es für die Bestimmung eines Zeitpunktes unwichtig ist. 12.08.12 08.00 Uhr UTC ->/ist/<- derselbe Zeitpunkt wie 12.08.12 06.00 Uhr MEZ. Du kannst in beiden Kalendern Zeiten erzeugen und wirst auf isEqual: YES erhalten. Das ist alles dem Date ziemlich egal. Wenn du willst, kannst du es auch in einen thailändischen Kelander in einer kongolesischen Zeitzone anzeigen lassen. Ändert immer noch nichts am Date.

So wie ich das kenne sind die in NSDate abgelegten Float Werte immer auf GMT bezogen, dass dir da was anderes in der GUI Angezeigt wird oder von componentsForDate zurückgeliefert wird, dass liegt dann am verwendeten Kalender und an der darin angenommen Zeitzone. Ob man aber in Berlin den 1.1.2012 00:00:00 unter Verwendung der MEZ eingibt oder in London 31.12.2011 23:00:00 ist dabei doch egal. In NSDate sollte exakt der gleiche Wert stehen. Wenn Du jetzt das NSDate persistent machst und durch die Welt reist, dann wird sich das in der GUI angezeigte Datum und die via components:FromDate: ermittelten Werte an die lokale Zeitzone anpassen sofern das System es tut.

Hier mal im Code:

Quellcode

int main(int argc, const char * argv[])

{

@autoreleasepool {

const NSUInteger dateComps = NSDayCalendarUnit | NSYearCalendarUnit | NSMonthCalendarUnit;

NSDate * now = [NSDate date];

NSCalendar * cal = [NSCalendar autoupdatingCurrentCalendar];

NSLog(@"Jetzt ist es in London: %@", now);

NSDate * begin = now;

// Die Uhrzeit ignorieren

NSDateComponents * comps = [cal components:dateComps

fromDate:begin];

NSLog(@"Verzinsung beginnt am: %lu.%lu.%lu", [comps day], [comps month], [comps year]);

begin = [cal dateFromComponents:comps];

NSLog(@"Zu Beginn des Tages war es in London: %@", begin);

// beginn in einer Datei speichern

NSDate * datumInEinerDatei = begin;

// Ab nach England.

NSLog(@"Ab nach London!");

[cal setTimeZone:[NSTimeZone timeZoneWithAbbreviation:@"GMT"]];

// beginn aus der Datei lesen

begin = datumInEinerDatei;

// Die Uhrzeit ignorieren

comps = [cal components:dateComps

fromDate:begin];

NSLog(@"Verzinsung beginnt am: %lu.%lu.%lu", [comps day], [comps month], [comps year]);

begin = [cal dateFromComponents:comps];

NSLog(@"Zu Beginn des Tages war es in London: %@", begin);

}

return 0;

}

Alles anzeigen

Ausgabe:

2012-10-25 21:59:34.710 DateExample[948:303] Jetzt ist es in London: 2012-10-25 19:59:34 +0000
2012-10-25 21:59:34.711 DateExample[948:303] Verzinsung beginnt am: 25.10.2012
2012-10-25 21:59:34.711 DateExample[948:303] Zu Beginn des Tages war es in London: 2012-10-24 22:00:00 +0000
2012-10-25 21:59:34.711 DateExample[948:303] Ab nach London!
2012-10-25 21:59:34.712 DateExample[948:303] Verzinsung beginnt am: 24.10.2012
2012-10-25 21:59:34.712 DateExample[948:303] Zu Beginn des Tages war es in London: 2012-10-24 00:00:00 +0000

Und siehe da, das Datum hat sich wie erwartet um einen Tag verschoben.

Und ja, mir ist klar, dass ein NSDate KEINE Zeitzone kennt.

Das sage ich doch gerade. Deshalb ist es eine Frage des Kalenders, in welcher Zeitzone du dich befindest. Und die Komponentenmethoden sind immer kalenderbezogen. Genau deshalb ist meine Lösung richtig.

Amin Negm-Awad · 25. Oktober 2012, 22:49

Snoxxi schrieb:

Nein, das NSDate welches Du vom NSDatePicker geliefert bekommst bezieht sich auf GMT und nicht auf die lokale Zeit. Deshalb ist das NSDate in London und Berlin bei gleicher Eingabe unterschiedlich.

Es ist richtig, dass das so ist, /weil/ NSDatePicker einen Kalender benutzt. Der rät das nicht.

Wenn du aber 12.06.43.08.17.33 als Eingabe bekommst, kann das lauten: 12. Juni 1943, 08:17:33 in MEZ, es kann aber auch bedeuten: 12 Minuten nach 06 und noch 43 Sekunden am 8. Tag der 17. Woche im Jahre 33 nach des Kaisers Geburt in der Zeitzone von Kalkutta.

beage · 25. Oktober 2012, 22:50

Das sage ich doch gerade. Deshalb ist es eine Frage des Kalenders, in welcher Zeitzone du dich befindest. Und die Komponentenmethoden sind immer kalenderbezogen. Genau deshalb ist meine Lösung richtig.

yap

Amin Negm-Awad · 25. Oktober 2012, 22:52

Um es noch einmal auf den Ursprung zurückzuführen:
@Amin: Bei deiner Methode zum entfernen der Uhrzeit hab ich dann doch Bauchschmerzen. Wo nimmt denn das dateFromComponents die Era, die Zeitzone und Co. her? Ich vermute ja, dass es die einfach von [NSDate date] ableitet und das ist nicht OK.

Er nimmt die Zeitzone eben nicht aus dem Date, sondern aus dem Kalender, in meinem Beispiel Gregorian.

beage · 25. Oktober 2012, 22:52

Amin Negm-Awad schrieb:

Snoxxi schrieb:

Nein, das NSDate welches Du vom NSDatePicker geliefert bekommst bezieht sich auf GMT und nicht auf die lokale Zeit. Deshalb ist das NSDate in London und Berlin bei gleicher Eingabe unterschiedlich.

Es ist richtig, dass das so ist, /weil/ NSDatePicker einen Kalender benutzt. Der rät das nicht.

Wenn du aber 12.06.43.08.17.33 als Eingabe bekommst, kann das lauten: 12. Juni 1943, 08:17:33 in MEZ, es kann aber auch bedeuten: 12 Minuten nach 06 und noch 43 Sekunden am 8. Tag der 17. Woche im Jahre 33 nach des Kaisers Geburt in der Zeitzone von Kalkutta.

geile Erklärung! Genau so!

Snoxxi · 26. Oktober 2012, 09:34

Snoxxi schrieb:

Nach einem bisschen Nachdenken, muss ich mich korrigieren. NSDate selbst kennt gar keine Zeitzone, die kommt erst durch den NSCalendar hinzu, wenn man für beide den gleichen Calendar inkl. Zeitzone verwendet, dann sollte alles Stimmen. Nichts desto trotz empfielt Apple ein anderes vorgehen sieh z.B. Listing 13.

Das habe ich etwa Zeitgleich - man sieht ja im Editor keine neuen Posts - zu deiner Antwort geschrieben. Wir sind uns also die ganze Zeit einig, das NSDate keine Zeitzone enthält und die Zeitzone erst erst durch die von NSDatePicker bzw. von beage benutzen Kalender ins Spiel kommt. Meine Kritik setzt jetzt da ein, dass Du suggerierst die Zeitzone wäre für beages Programm egal und er müsste sich nicht darum kümmern. In meinen Augen ist das einfach Falsch, den wenn er sich nicht um die Zeitzonen kümmert, dann werden die Kalender bei ihrer Erzeugung die von ihnen verwendete Zeitzone aus den Systemeinstellungen holen. Was dann, zu Unterschiedlichen Zeitzonen in den verwendeten Kalendern führen kann und das liefert dann die von mir beschriebenen Effekte.

beage · 26. Oktober 2012, 09:46

Ich hätte je nicht gedacht, dass ich hier so eine Diskussion anrege. Vielleicht nochmal zur Erklärung:

Ich habe 2 Datepicker, wo der User jeweils ein Start- und ein Ende-Datum auswählt. Ich initialisiere das Startdatum mit dem 01.01.2011 und das Endedatum mit now. Dann wandle ich beide Daten in ein NSDate um.
im Startdatum seht jetzt z.B. 03.09.2008 01:00:00 CET (Hier kommt die Zeitzone zum Tragen) und im Endedatum stehen das aktuelles Datum und die Uhrzeit, z.B. 26.10.2012 09:41:23 CET.

Da ich später in meinem Programmablauf einen Datumsvergleich machen muss und die Uhrzeit ja mitverglichen wird, setze ich die Uhrzeit programmatisch mit setHour usw. auf 0.
Danach stehen in den NSDates 03.09.2008 00:00:00 CET und 26.10.2012 00:00:00 CET. Im weiteren Programmablauf shifte ich das Startdatum in einer Schleife pro Durchlauf um 1 Tag. Die Uhrzeit verändert sich dadurch aber nicht mehr.

Amin Negm-Awad · 26. Oktober 2012, 09:47

Snoxxi schrieb:

Snoxxi schrieb:

Nach einem bisschen Nachdenken, muss ich mich korrigieren. NSDate selbst kennt gar keine Zeitzone, die kommt erst durch den NSCalendar hinzu, wenn man für beide den gleichen Calendar inkl. Zeitzone verwendet, dann sollte alles Stimmen. Nichts desto trotz empfielt Apple ein anderes vorgehen sieh z.B. Listing 13.

Das habe ich etwa Zeitgleich - man sieht ja im Editor keine neuen Posts - zu deiner Antwort geschrieben. Wir sind uns also die ganze Zeit einig, das NSDate keine Zeitzone enthält und die Zeitzone erst erst durch die von NSDatePicker bzw. von beage benutzen Kalender ins Spiel kommt. Meine Kritik setzt jetzt da ein, dass Du suggerierst die Zeitzone wäre für beages Programm egal und er müsste sich nicht darum kümmern. In meinen Augen ist das einfach Falsch, den wenn er sich nicht um die Zeitzonen kümmert, dann werden die Kalender bei ihrer Erzeugung die von ihnen verwendete Zeitzone aus den Systemeinstellungen holen. Was dann, zu Unterschiedlichen Zeitzonen in den verwendeten Kalendern führen kann und das liefert dann die von mir beschriebenen Effekte.

1. Das Listing 13 berechnet die Differenz zwischen zwei Daten. Hier ging es zunächst darum, dass er zunächst einen festen Zeitpunkt im Tag haben wollte. Das kann viele Gründe haben, eine Berechnung von Differenzen ist nur eine davon. (Übrigens macht es das Gesetz, das ja dasselbe Problem bei Fristen hat, ebenso. Was ist ein Monat ab dem 30.01.2013, 17:53:12?) Ich habe schon feste Zeitpnkte am Tag benötigt, um ein Prädikat aufzusetzen, welches ein Ereignis für einen Tag herausfischt.

Übrigens muss bei dem Sample von Apple, welches eine Kategorie von NSCalendar ist(!), die Zeitzone außerhalb der Methode richtig gesetzt worden sein. Das heißt, dass bereits außerhalb(!) der Methode irgendeine Eingabe mittels eines Kalenders mit der richtigen Zeitzone in ein Datum umgewandelt worden sein muss.

2. Wir sind uns nicht die ganze Zeit einig, sondern erst seitdem du dich gestern um halb 2 korrigiert hast. Die Korrektur hatte ich übrigens gar nicht gesehen, sondern erst jetzt, da ich auf den Beitrag bereits geantwortet hatte und die Korrektur 1,5 h später erfolgte.

3. Ich suggeriere auch nicht, dass Zeitzonen bei meiner Lösung kein Problem seien. Ich sage vielmehr, dass wenn man die berücksichtigen möchte, man sie eben berücksichtigen muss. Und ich sage auch, dass man sie bei dem Kalender und nicht beim Datum berücksichtigen muss. Und ich sage, dass das genau so richtig und gewollt ist, weil die Zeitzone eine Eigenschaft des Kalenders ist. Dazu habe ich auch Samplecode gepostet.

Snoxxi · 26. Oktober 2012, 10:31

beage schrieb:

Ich hätte je nicht gedacht, dass ich hier so eine Diskussion anrege. Vielleicht nochmal zur Erklärung:

Ich habe 2 Datepicker, wo der User jeweils ein Start- und ein Ende-Datum auswählt. Ich initialisiere das Startdatum mit dem 01.01.2011 und das Endedatum mit now. Dann wandle ich beide Daten in ein NSDate um.
im Startdatum seht jetzt z.B. 03.09.2008 01:00:00 CET (Hier kommt die Zeitzone zum Tragen) und im Endedatum stehen das aktuelles Datum und die Uhrzeit, z.B. 26.10.2012 09:41:23 CET.

Da ich später in meinem Programmablauf einen Datumsvergleich machen muss und die Uhrzeit ja mitverglichen wird, setze ich die Uhrzeit programmatisch mit setHour usw. auf 0.
Danach stehen in den NSDates 03.09.2008 00:00:00 CET und 26.10.2012 00:00:00 CET. Im weiteren Programmablauf shifte ich das Startdatum in einer Schleife pro Durchlauf um 1 Tag. Die Uhrzeit verändert sich dadurch aber nicht mehr.

Das Problem was ich hier sehe und welches ich die ganze Zeit darzustellen versuche ist, dass Du mehrere Kalender verwendest, die u.U. andere Zeitzonen haben können. Deine ganzen Annahmen, dass das immer CET ist, sind dann nicht korrekt. Wenn Du die Berechnungen - insbesondere auch die Analysen bzgl. der Zinsgrenzen - startest, dann kann das NSDate plötzlich mit einer ganz anderen Zeitzone interpretiert werden als bei der Eingabe im GUI. Für eine Termindatenbank ist das im allg. auch genau dass was Du willst aber in deinem Fall willst Du eben alles in CET haben. Ich würde Vermuten, dass Du via NSTimeZones setDefaultTimeZone: deine App aber dazu bringen kannst sich genau so zu verhalten.

beage · 26. Oktober 2012, 10:40

In der Tat! Ich hab jetzt mal meine Zeitzone im System auf VAT (Russland) gestellt. Im Eingabefeld steht zwar immer noch der 1.1.2011, aber im NSDate der 2.1.2011. Shit!

Amin Negm-Awad · 26. Oktober 2012, 10:45

Snoxxi schrieb:

beage schrieb:

Ich hätte je nicht gedacht, dass ich hier so eine Diskussion anrege. Vielleicht nochmal zur Erklärung:

Ich habe 2 Datepicker, wo der User jeweils ein Start- und ein Ende-Datum auswählt. Ich initialisiere das Startdatum mit dem 01.01.2011 und das Endedatum mit now. Dann wandle ich beide Daten in ein NSDate um.
im Startdatum seht jetzt z.B. 03.09.2008 01:00:00 CET (Hier kommt die Zeitzone zum Tragen) und im Endedatum stehen das aktuelles Datum und die Uhrzeit, z.B. 26.10.2012 09:41:23 CET.

Da ich später in meinem Programmablauf einen Datumsvergleich machen muss und die Uhrzeit ja mitverglichen wird, setze ich die Uhrzeit programmatisch mit setHour usw. auf 0.
Danach stehen in den NSDates 03.09.2008 00:00:00 CET und 26.10.2012 00:00:00 CET. Im weiteren Programmablauf shifte ich das Startdatum in einer Schleife pro Durchlauf um 1 Tag. Die Uhrzeit verändert sich dadurch aber nicht mehr.

Das Problem was ich hier sehe und welches ich die ganze Zeit darzustellen versuche ist, dass Du mehrere Kalender verwendest, die u.U. andere Zeitzonen haben können. Deine ganzen Annahmen, dass das immer CET ist, sind dann nicht korrekt. Wenn Du die Berechnungen - insbesondere auch die Analysen bzgl. der Zinsgrenzen - startest, dann kann das NSDate plötzlich mit einer ganz anderen Zeitzone interpretiert werden als bei der Eingabe im GUI. Für eine Termindatenbank ist das im allg. auch genau dass was Du willst aber in deinem Fall willst Du eben alles in CET haben. Ich würde Vermuten, dass Du via NSTimeZones setDefaultTimeZone: deine App aber dazu bringen kannst sich genau so zu verhalten.

Natürlich muss er die Zeitznen bei der Eingabe berücksichtigen. Entsprechenden Samplecode habe ich gepostet.