Dates

[robertmryan]

In your documentation, you suggest the following NSDateFormatter:

let SQLDateFormatter: NSDateFormatter = {
    let formatter = NSDateFormatter()
    formatter.dateFormat = "yyyy-MM-dd HH:mm:ss"
    formatter.timeZone = NSTimeZone(abbreviation: "UTC")
    return formatter
}()

I'd make a few suggestions:

• I'd suggest you also set the locale of the NSDateFormatter to NSLocale(localeIdentifier: "en_US_POSIX") in order to ensure that you don't have problems with users/developers using non-Gregorian calendars. See Technical Q&A 1480.

• I'd also suggest including the time zone in the string. If you want to handle it like NSLog, you could write it with nice human readable +0000. Or if you want to conform to ISO8601/RFC3339 standards, you'd put a T between the date and the time and append a Z at the end to designate that it's "Zulu".

  Personally, I'd also have the default behavior to include milliseconds (SSS in the format string, too), and perhaps adopt the ISO 8601 style, e.g. yyyy-MM-dd'T'HH:mm:ss.SSS'Z').

• It's up to you, but rather than proper date handling being a comment in the documentation, and leaving it to the developer to implement it correctly (and, as evidenced by Stack Overflow, most of them won't), I might suggest incorporating it right into the class, so that, by default, the app developer has a good solid handling of NSDate parameters. Maybe make the NSDateFormatter property that the library uses a read/write property that the developer can override with whatever they want. But default it to some well-established best practice, perhaps something like what we've outlined above.

[stephencelis]

Thanks for the suggestions!

• I'll update to set the locale accordingly.

• I was merely using a format consistent with the output of CURRENT_TIMESTAMP, which can be used as a column default, and would unfortunately lose the precision of manually-set dates (this could, of course, be fixed by using a strftime in SQLite).

  SELECT CURRENT_TIMESTAMP
  --- 2015-02-03 21:02:46

  The first version of the documentation used your suggested format. I'll consider reverting back to it.

• I'm planning on releasing a SQLite+Foundation.framework of sorts in the future that will add just this, but wanted the bare library to be a little less opinionated and a little more pure-Swift.

[robertmryan]

Thanks for taking the time to respond.

I'll respectfully agree to disagree on the decision to not including some timezone designation, but I certainly understand and appreciate your rationale.

Best wishes.

[stephencelis]

I'll respectfully agree to disagree on the decision to not including some timezone designation, but I certainly understand and appreciate your rationale.

I'm not sure if you mean to come across as argumentative. As I mentioned, the decision is not closed and the format you suggested may come back in a future commit.

If you use SQLite.swift in a future project and have any more comments/suggestions, please send them my way.