NSDate in Core Data

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

Aufgrund der Corona-Krise: Die Veröffentlichung von Stellenangeboten und -gesuchen ist bis 31.12.2021 kostenfrei. Das beinhaltet auch Angebote und Gesuche von und für Freischaffende und Selbstständige.

  • NSDate in Core Data

    Hallo

    Wie kann man einen NSDate in Core Data erstellen bzw. anzeigen lassen? Ich habe in meiner Entity ein Attribut namens 'datum' vom Typ 'Date' erstellt. Die Idee war, dass das Datum beim Abspeichern der anderen Attribute als Datum in der TableViewCell erscheint.

    Es funktioniert alles, ausser das das NSDate nicht angezeigt wird bzw. es wird eine Fehlermeldung erzeugt, die wie folgt lautet: "Cannot assign value of type 'String' to type 'NSDate?'.

    Nachstehend noch der entsprechende Codeschnipsel:

    Quellcode

    1. let currentDate = NSDate()
    2. let dateFormatter = NSDateFormatter()
    3. dateFormatter.locale = NSLocale(localeIdentifier: "de_DE")
    4. dateFormatter.dateStyle = NSDateFormatterStyle.MediumStyle
    5. dateFormatter.stringFromDate(currentDate)
    6. let bmi = NSEntityDescription.insertNewObjectForEntityForName("BMI", inManagedObjectContext: AppDelegate.sharedInstance.managedObjectContext) as! BMI
    7. bmi.bmiwert = Float(ausgabeBMILabel.text!) // Text in Float umwandeln!
    8. bmi.datum = dateFormatter.stringFromDate(currentDate)

    Die oben erwähnte Fehlermeldung erscheint in Zeile 'bmi.datum = dateFormatter.stringFromDate(currentDate)'.

    Ist es überhaupt möglich NSDate z.B. als String in Core Data umzuwandeln und falls ja, ist da ein besonderes Vorgehen zu beachten?

    Besten für alle Hinweise!
  • macmoonshine schrieb:

    Grundsätzlich solltest du programmintern für ein Datum immer NSDate oder zur Not NSTimeInterval verwenden und keine Strings. Eine Datumszeichenkette ist ein Darstellung eines Datums, und sollte deshalb auch nur für die externe (Bildschirm-)darstellung oder Speicherung in Textdateien verwendet werden.
    Naja und damit Core Data es in die sql DB schreiben kann wandelt es den dann wieder in einen String (datetime) oder benuzten die noch timeinterval?

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Thallius schrieb:

    macmoonshine schrieb:

    Grundsätzlich solltest du programmintern für ein Datum immer NSDate oder zur Not NSTimeInterval verwenden und keine Strings. Eine Datumszeichenkette ist ein Darstellung eines Datums, und sollte deshalb auch nur für die externe (Bildschirm-)darstellung oder Speicherung in Textdateien verwendet werden.
    Naja und damit Core Data es in die sql DB schreiben kann wandelt es den dann wieder in einen String (datetime) oder benuzten die noch timeinterval?
    Gruß

    Claus
    Würde mich doch sehr wundern wenn apple das al string und nicht als number speichern würde - aber denkbar ist ja alles...
  • Thallius schrieb:

    Naja und damit Core Data es in die sql DB schreiben kann
    CoreData ist ja eine Persistenzschicht und keine Datenbank. Wie das letztendlich dann im Backend abgelegt wird, kann Dir doch wurscht sein. Das ist ein Implementierungsdetail, um das Du dich i.a. nicht kümmern musst. Wenn Du stattdessen zur Darstellung einen String verwendest, bist Du bei Datumsoperationen doch ständig am hin- und herkonvertieren zwischen NSDate und NSString. Wobei ich finde, dass NSDate für viele Anwendungen "oversized" ist, da es halt einen genauen Zeitpunkt beschreibt (Also Date + Time) oftmals aber der Zeitpunkt nicht interessiert. Aber das nur am Rande.

    schönen Gruß

    gandhi
  • gritsch schrieb:

    Thallius schrieb:

    macmoonshine schrieb:

    Grundsätzlich solltest du programmintern für ein Datum immer NSDate oder zur Not NSTimeInterval verwenden und keine Strings. Eine Datumszeichenkette ist ein Darstellung eines Datums, und sollte deshalb auch nur für die externe (Bildschirm-)darstellung oder Speicherung in Textdateien verwendet werden.
    Naja und damit Core Data es in die sql DB schreiben kann wandelt es den dann wieder in einen String (datetime) oder benuzten die noch timeinterval?Gruß

    Claus
    Würde mich doch sehr wundern wenn apple das al string und nicht als number speichern würde - aber denkbar ist ja alles...
    Wie sieht denn bei Dir ein SQL Query aus bei dem Du ein DateTime befüllst?
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • gandhi schrieb:

    Thallius schrieb:

    Naja und damit Core Data es in die sql DB schreiben kann
    CoreData ist ja eine Persistenzschicht und keine Datenbank. Wie das letztendlich dann im Backend abgelegt wird, kann Dir doch wurscht sein. Das ist ein Implementierungsdetail, um das Du dich i.a. nicht kümmern musst. Wenn Du stattdessen zur Darstellung einen String verwendest, bist Du bei Datumsoperationen doch ständig am hin- und herkonvertieren zwischen NSDate und NSString. Wobei ich finde, dass NSDate für viele Anwendungen "oversized" ist, da es halt einen genauen Zeitpunkt beschreibt (Also Date + Time) oftmals aber der Zeitpunkt nicht interessiert. Aber das nur am Rande.
    schönen Gruß

    gandhi
    Ich habe ja nicht behauptet das man mit einem String arbeiten soll, Natuerlich sollte Dir das egal sein, nur klang Moon sein Post so als ob man dates niemals als String speichern sollte. Im Endeffekt macht SQL aber nichts anderes wenn du datetime als Format angibst.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Thallius schrieb:

    gritsch schrieb:

    Thallius schrieb:

    macmoonshine schrieb:

    Grundsätzlich solltest du programmintern für ein Datum immer NSDate oder zur Not NSTimeInterval verwenden und keine Strings. Eine Datumszeichenkette ist ein Darstellung eines Datums, und sollte deshalb auch nur für die externe (Bildschirm-)darstellung oder Speicherung in Textdateien verwendet werden.
    Naja und damit Core Data es in die sql DB schreiben kann wandelt es den dann wieder in einen String (datetime) oder benuzten die noch timeinterval?Gruß
    Claus
    Würde mich doch sehr wundern wenn apple das al string und nicht als number speichern würde - aber denkbar ist ja alles...
    Wie sieht denn bei Dir ein SQL Query aus bei dem Du ein DateTime befüllst?
    es gibt doch kein DateTime!
    ich verwende numerische timestamps (mit timezone +-0).
  • Thallius schrieb:

    gandhi schrieb:

    Thallius schrieb:

    Naja und damit Core Data es in die sql DB schreiben kann
    CoreData ist ja eine Persistenzschicht und keine Datenbank. Wie das letztendlich dann im Backend abgelegt wird, kann Dir doch wurscht sein. Das ist ein Implementierungsdetail, um das Du dich i.a. nicht kümmern musst. Wenn Du stattdessen zur Darstellung einen String verwendest, bist Du bei Datumsoperationen doch ständig am hin- und herkonvertieren zwischen NSDate und NSString. Wobei ich finde, dass NSDate für viele Anwendungen "oversized" ist, da es halt einen genauen Zeitpunkt beschreibt (Also Date + Time) oftmals aber der Zeitpunkt nicht interessiert. Aber das nur am Rande.schönen Gruß

    gandhi
    Ich habe ja nicht behauptet das man mit einem String arbeiten soll, Natuerlich sollte Dir das egal sein, nur klang Moon sein Post so als ob man dates niemals als String speichern sollte. Im Endeffekt macht SQL aber nichts anderes wenn du datetime als Format angibst.
    Gruß

    Claus
    Nein das stimmt NICHT!
    datetime gibts bei SQLITE nicht.
    Wenn du MySQL meinst, dann wird es auch da nicht als string gespeichert sondern in 8 bytes (3 bytes davon für sekundenbruchteile).
    dev.mysql.com/doc/refman/5.7/en/storage-requirements.html
  • gritsch schrieb:

    Thallius schrieb:

    gritsch schrieb:

    Thallius schrieb:

    macmoonshine schrieb:

    Grundsätzlich solltest du programmintern für ein Datum immer NSDate oder zur Not NSTimeInterval verwenden und keine Strings. Eine Datumszeichenkette ist ein Darstellung eines Datums, und sollte deshalb auch nur für die externe (Bildschirm-)darstellung oder Speicherung in Textdateien verwendet werden.
    Naja und damit Core Data es in die sql DB schreiben kann wandelt es den dann wieder in einen String (datetime) oder benuzten die noch timeinterval?GrußClaus
    Würde mich doch sehr wundern wenn apple das al string und nicht als number speichern würde - aber denkbar ist ja alles...
    Wie sieht denn bei Dir ein SQL Query aus bei dem Du ein DateTime befüllst?
    es gibt doch kein DateTime!ich verwende numerische timestamps (mit timezone +-0).
    Bei sqlite nicht bei mysql, sql etc schon.
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Thallius schrieb:

    gritsch schrieb:

    Thallius schrieb:

    gritsch schrieb:

    Thallius schrieb:

    macmoonshine schrieb:

    Grundsätzlich solltest du programmintern für ein Datum immer NSDate oder zur Not NSTimeInterval verwenden und keine Strings. Eine Datumszeichenkette ist ein Darstellung eines Datums, und sollte deshalb auch nur für die externe (Bildschirm-)darstellung oder Speicherung in Textdateien verwendet werden.
    Naja und damit Core Data es in die sql DB schreiben kann wandelt es den dann wieder in einen String (datetime) oder benuzten die noch timeinterval?GrußClaus
    Würde mich doch sehr wundern wenn apple das al string und nicht als number speichern würde - aber denkbar ist ja alles...
    Wie sieht denn bei Dir ein SQL Query aus bei dem Du ein DateTime befüllst?
    es gibt doch kein DateTime!ich verwende numerische timestamps (mit timezone +-0).
    Bei sqlite nicht bei mysql, sql etc schon.
    Und auch da wird so ein datum NICHT als string gespeichert (siehe mein letztes posting).
  • Thallius schrieb:

    Naja und damit Core Data es in die sql DB schreiben kann wandelt es den dann wieder in einen String (datetime) oder benuzten die noch timeinterval?
    Woher weißt du, wie SQLite die Daten intern ablegt?

    Entscheidend ist aber etwas anderes: Wenn ich den SQL-Typ DATE verwende, kann SQLite (oder CoreData) damit etwas damit anfangen. Beispielsweise kann ich Datumsobjekte richtig miteinander vergleichen oder ordnen oder man kann damit rechnen (z B. + drei Tage). Mit Strings ist das ein unheimliches Gewurstel.

    Es ist leider so, dass gerade Anfänger gerne einfache Datentypen (z. B. Zahlen, URLs, Datums- und Zeitobjekte, XML) mit ihrer Stringdarstellung verwechseln. Das führt dann häufig zu entsprechendem wüsten Code.
    „Meine Komplikation hatte eine Komplikation.“