CoreData NSDate SQLite 精度差异
我看到了一些围绕这个主题的问题，但没有一个是完全匹配的。
我正在创建时间戳作为主键的一部分。时间戳使用 [NSDate date] 设置并存储在 SQLite 存储中。当我查看商店时，日期具有完全精度（最多 7 位小数，表示 100 纳秒精度）。
我有在服务器上运行的服务，我需要向其发送数据并从中检索日期。发送过程序列化数据，为了以所需的精度发送日期（在 SQL Server 中存储为 datetime2），我使用：
NSDateFormatter *dateFormat = [[NSDateFormatter alloc]init];
[dateFormat setDateFormat:@"yyyy-MM-dd'T'HH:mm:ss.SSSSSSS'Z'"];
NSString *stringFromDate = [dateFormat stringFromDate:dateTime];
，从服务器检索日期时反之亦然。
问题在于，由于某种原因，从存储中检索的日期仅达到毫秒精度。因此，如果我在商店中有一个时间戳为 341196557.808558，检索到 NSDate 中，然后使用上面的代码生成一个读取为“2011-10-24'T'08:48:17.8090000”的字符串。
这会被发送到服务器，服务器会尽职尽责地将其存储为毫秒精度（因为这就是它所获得的全部）。然后，当我检索日期、反序列化它并尝试对存储使用谓词获取时，它不会返回记录，因为日期不相等。做一个<或>比较不起作用，因为它是主键...我需要==
我不介意在保存之前将时间戳的精度降低到毫秒（如果我能弄清楚如何），但对我来说，原始的似乎非常奇怪date 可以存储和保存微秒精度，但从存储中检索日期时不保持相同的精度？
希望对此有任何想法，或者解决这个混乱的宝石单行......
I've seen a few questions which float around this topic but nothing which quite matches.
I'm creating a Timestamp as part of a primary key. The timestamp is set with [NSDate date] and is stored in a SQLite store. When I look into the store the dates have full precision (up to 7 decimal places indicating 100 nanosecond precision).
I have services running on a server which I need to send the data to and retrieve the date from. The sending process serializes the data and in order to send the date with the required precision (stored as datetime2 in SQL Server) I use:
NSDateFormatter *dateFormat = [[NSDateFormatter alloc]init];
[dateFormat setDateFormat:@"yyyy-MM-dd'T'HH:mm:ss.SSSSSSS'Z'"];
NSString *stringFromDate = [dateFormat stringFromDate:dateTime];
and vice versa when retrieving the date from the server.
The problem is that the date being retrieved from the store is for some reason ONLY at millisecond precision. So if I have a Timestamp in the store as 341196557.808558, retrieve into an NSDate and then use the above code to generate a string is reads as "2011-10-24'T'08:48:17.8090000".
This gets sent to the server which dutifully stores it as millisecond precision (because that's all it's getting). When I then retrieve the date, deserialize it and try and use a predicate fetch against the store it doesn't return the record because the dates aren't equal. Doing a < or > comparison won't work because it's a primary key... I need ==
I wouldn't mind dropping to millisecond precision on the timestamp prior to saving (if I could work out how) but it seems extremely odd to me that the original date can store and save microsecond precision but doesn't keep the same precision when retrieving the date from the store?
Would love any thoughts on this, or that gem one-liner which sorts this mess out...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
虽然我不知道为什么纳秒精度会下降（这让我感到惊讶，你应该对其进行雷达归档），但我可以说的是：
时间戳是一个可怕的主键。如果你能改变这一点，我强烈推荐它。
如果您必须使用时间戳，那么我建议将
-timeIntervalSinceReferenceDate存储在 Core Data 中，然后在需要将其发送到服务器时重建日期。更新
从纯粹的数据库角度来看，
时间戳是一种痛苦（正如您所经历的）并且浪费，因为您永远不会按顺序使用所有时间戳。根据您尝试执行的操作，INT64 增量（对于 Core Data 来说并不容易）效果很好。如果您使用的时间戳不仅仅是唯一键的一部分，那么我将按照我上面的建议将其保留为 NSTimeInterval （双精度）。这将保持你的精确度并避免弄乱琴弦。请记住，字符串可能非常慢。
While I do not know why the nanosecond precision is being dropped (that surprises me and you should file a radar on it) what I can say is that:
Timestamps are a terrible primary key. If you can change that I would highly recommend it.
If you must use Timestamps then I suggest storing the
-timeIntervalSinceReferenceDatein Core Data instead and then reconstruct the date whenever you need to send it to the server.Update
Timestamps are a pain (as you are experiencing) and wasteful from a purely DB point of view since you never use all of them in order.
Depending on what you are trying to do a INT64 incremented (not easy with Core Data) works well. If you are using the timestamp for more than just part of the unique key then I would just keep it as a NSTimeInterval (double) as I suggested above. That will keep your precision and avoid messing with strings. Keep in mind that strings can be quite slow.