Date parsing performance on iOS (NSDateformatter vs sqlite)
vombat.tumblr.com
Date parsing performance on iOS (NSDateformatter vs sqlite)
1–10 of 63 posts
Re: Date parsing performance on iOS (NSDateformatter vs sqlite)
#2I wonder if this could be improved by just using the standard C library strftime(3) instead of going through sqlite?
Re: Date parsing performance on iOS (NSDateformatter vs sqlite)
#3>Many web services choose to return dates in something other than a unix timestamp (unfortunately)
Wrong. That's very fortunate. Unix time stamps have some serious deficiencies as data type for storing time information: for one, they lack precision. One second just might not do it. Then they lack any time zone information. You will never know what a specific time stamp is in. GMT? UTC? Time zone where the server is in?
Sure. Maybe you are lucky and it's documented (it probably isn't because people who care about such things are not using unix time stamps to begin with), but using a string time stamp formatted in ISO means that no documentation is needed. The encoding is good enough to store any sub second time stamp including time zone info.
That way, you can turn any of these into whatever your environment uses internally which you will then use in conjunction with the library routines to deal with all the difficulties related to doing math with dates (how many days in a month? What about leap years? What about time zones? Not really hard issues, but many to keep in mind and many possible causes for bugs)
Re: Date parsing performance on iOS (NSDateformatter vs sqlite)
#4>Many web services choose to return dates in something other than a unix timestamp (unfortunately) Wrong. That's very fortunate. Unix time stamps have some serious deficiencies as data type for storing time information: for one, they lack precision. One second just might not do it. Then they lack any time zone information. You will never know what a specific time stamp is in. GMT? UTC? Time zone where the server is i…
The other major advantage of using ISO 8601 is it's human readable. Very few people are going to be able to look at a Unix timestamp and convert it in their head (...if you can that's a good party trick).
Re: Date parsing performance on iOS (NSDateformatter vs sqlite)
#5>Many web services choose to return dates in something other than a unix timestamp (unfortunately) Wrong. That's very fortunate. Unix time stamps have some serious deficiencies as data type for storing time information: for one, they lack precision. One second just might not do it. Then they lack any time zone information. You will never know what a specific time stamp is in. GMT? UTC? Time zone where the server is i…
Precision can be fixed by just adding a decimal point. And a "UNIX time stamp" doesn't need a time zone because it's always UTC.
However, you're overall point there remains valid, because people will try to pass off something as a "UNIX time stamp" that is actually in a different time zone. There is value to self-describing data.
Re: Date parsing performance on iOS (NSDateformatter vs sqlite)
#6terrible use of percentages.
Re: Date parsing performance on iOS (NSDateformatter vs sqlite)
#7I wonder if this could be improved by just using the standard C library strftime(3) instead of going through sqlite?
If date formatting is a bottleneck for me (it is surprisingly often, because it's very slow in some languages) I typically just run it through the command-line program 'convdate' [1] from crush-tools, which is more or less just a wrapper around strptime+strftime.
[1] https://code.google.com/p/crush-tools/wiki/ConvdateUserDocs
Re: Date parsing performance on iOS (NSDateformatter vs sqlite)
#8>Many web services choose to return dates in something other than a unix timestamp (unfortunately) Wrong. That's very fortunate. Unix time stamps have some serious deficiencies as data type for storing time information: for one, they lack precision. One second just might not do it. Then they lack any time zone information. You will never know what a specific time stamp is in. GMT? UTC? Time zone where the server is i…
A string timestamp needs more documentation, because there are many subtly different string formats. Does it refer to a specific instant, or a political time notion? What separator is in use? Are leap seconds a possibility?
The ISO date format's notion of timezones is a compromise that gives you the worst of all worlds. They complicate referring to a physical instant, because you can refer to it in several timezones, rather than the unique representation of a unix timestamp. But they're inadequate for political time, because what time comes 6 months after 13:00 (+00:00)? (It could be 13:00 (+01:00) or 13:00 (+00:00) or likely others - you need a symbolic timezone like "Europe/Lisbon").
For physical or "system" times unix time is great (unless you need the greater precision, but how common is that?). For user-facing times ISO is inadequate. The use case for ISO string datetime formats is very narrow.
Re: Date parsing performance on iOS (NSDateformatter vs sqlite)
#9>Many web services choose to return dates in something other than a unix timestamp (unfortunately) Wrong. That's very fortunate. Unix time stamps have some serious deficiencies as data type for storing time information: for one, they lack precision. One second just might not do it. Then they lack any time zone information. You will never know what a specific time stamp is in. GMT? UTC? Time zone where the server is i…
Unix timestamps are always UTC (GMT)
Quote:
> Unix time, or POSIX time, is a system for describing instants in time, defined as the number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970
Re: Date parsing performance on iOS (NSDateformatter vs sqlite)
#10That's bad. Very bad. iOS Apps use timestamp everywhere so I'm sure this could be a low hanging fruit optimization for many apps out there.
You should wrap this piece of code in a nice API and let people benefit from your findings. (Someone else could do it too, I'm just saying!)