For those million timestamps I am sure that those extra allocations from the statement APIs are not helpful. Since he references the C code sqlite is using (at a quick glance it looks pretty contained) I don't know why he doesn't just include it directly in his project and call it from objc, no statement API needed. [Edit: I see now that in the test there is only 1 statement object ever created for a test of a millio…
Date parsing performance on iOS (NSDateformatter vs sqlite)
61–63 of 63 posts
Re: Date parsing performance on iOS (NSDateformatter vs sqlite)
#62Earlier quoted context omitted.
There is nothing preventing you from sending a time zone offset (or an Olson timezone id like 'America/Los_Angeles') along with the Unix Time.
Sure no problem. We just have to invent a new format.
{timestamp: xyz, tz: "America/Los_Angeles"}
Re: Date parsing performance on iOS (NSDateformatter vs sqlite)
#63Earlier quoted context omitted.
More importantly (the GP missed this as well), Unix timestamps can't convey local time . Local time has UI implications, e.g. the query "is this event on a weekend" is not generally answerable without the time zone.
Entirely true, but not necessarily relevant. Local time is a weird thing and changes all the time. For giggles, look at the history of timezone rule changes in tzdata. Most timezones have at least one duplicate hour per year (IE the same time occurs twice) in the US as well. Local times are not an appropriate way to store time. Note: ISO8601 does not give you local time anyway, since you cannot infer the timezone fro…
That you cannot infer the timezone from the time offset in ISO 8601 is a good point though.