Why convert each date with a select if they are putting it into the db anyway? Why not just let sqlite do the conversion as part of the insert statement?
Date parsing performance on iOS (NSDateformatter vs sqlite)
11–20 of 63 posts
Re: Date parsing performance on iOS (NSDateformatter vs sqlite)
#12>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,…
"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."
I thought it's supposed to be an external format. I'd always expect a computer system presenting the output information to the user in his local time zone, while accepting inputs from all time zones equally.
"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")."
You can't standardize a changing practice. I'd never expect it to deal with these issues.
Re: Date parsing performance on iOS (NSDateformatter vs sqlite)
#13terrible use of percentages.
Yea, 15 times faster would have be much clearer. On the other hand, 1400% has "shock value" and makes for a very link-baity title.
Re: Date parsing performance on iOS (NSDateformatter vs sqlite)
#14>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
My experience suggests that's not always the case :(.
Re: Date parsing performance on iOS (NSDateformatter vs sqlite)
#15These two methods start producing different dates after about year 3515.
Re: Date parsing performance on iOS (NSDateformatter vs sqlite)
#16Earlier quoted context omitted.
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
My experience suggests that's not always the case :(.
This is a standard as well as a convention. People breaking it are idiots. Most software out there assumes UTC time when dealing with Unix timestamps. Most Java date libraries handle this perfectly and get the correct timezone.
Re: Date parsing performance on iOS (NSDateformatter vs sqlite)
#17>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
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.
Re: Date parsing performance on iOS (NSDateformatter vs sqlite)
#18I 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
If it is a bottleneck shelling out is not a great solution...
Re: Date parsing performance on iOS (NSDateformatter vs sqlite)
#19Earlier quoted context omitted.
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
If it is a bottleneck shelling out is not a great solution...
Shelling out for each piece of data is indeed not great.
Shelling out for batch-processing loads of data is on the other hand great.
Re: Date parsing performance on iOS (NSDateformatter vs sqlite)
#20>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…
Another good reason to avoid POSIX timestamps: they ignore leap-seconds. Thus, to determine how many (for example) days are between two timestamps, you need an up-to-date database of leap-second insertions. Maybe an error-bar of a few seconds doesn't sound like much, but if that error bar happens to straddle midnight and (like most code) you get a date-stamp by truncation, you could be off by a day. If that error-bar happens to straddle midnight on December 31st and you're truncating to month or year values, you could be out by a whole lot more.