Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Date is not correctly saved #1214

Open
LittleLydia opened this issue Jun 7, 2023 · 2 comments
Open

Date is not correctly saved #1214

LittleLydia opened this issue Jun 7, 2023 · 2 comments

Comments

@LittleLydia
Copy link

Issues are used to track bugs and feature requests.
Need help or have a general question? Ask on Stack Overflow (tag sqlite.swift).

Build Information

  • Include the SQLite.swift version, commit or branch experiencing the issue.
  • Mention Xcode and OS X versions affected.
  • How do do you integrate SQLite.swift in your project?
    • manual
    • CocoaPods
    • Carthage
    • Swift Package manager

SQLite.swift version = 0.92
Xcode version = 14.1
macOS version = 13.2.1

General guidelines

  • Be as descriptive as possible.
  • Provide as much information needed to reliably reproduce the issue.
  • Attach screenshots if possible.
  • Better yet: attach GIFs or link to video.
  • Even better: link to a sample project exhibiting the issue.

I use touch to create a new file ,zero bytes , like touch abcd.
then I read the modificationDate by using
let modifyDate = try FileManager.default.attributesOfItem(atPath: wholePath)[.modificationDate] as? Date
its description like this
`▿ 2023-06-07 02:14:52 +0000

  • timeIntervalSinceReferenceDate : 707796892.7651631`

but after I fetch it from the db.sqlite, it turns out to be:
▿ 2023-06-07 02:14:52 +0000

  • timeIntervalSinceReferenceDate : 707796892.7650001

Other files which is larger than zero bytes are fine. Just this one. I am really sure before I save it in the db, it is 707796892.7651631

Don't know why

@geoffmacd
Copy link
Contributor

Precision is lost from the date formatter that is used internally to store the date.

If you need perfect precision you need to store dates as a double. Otherwise you cannot guarantee equality.

@LittleLydia
Copy link
Author

Precision is lost from the date formatter that is used internally to store the date.

If you need perfect precision you need to store dates as a double. Otherwise you cannot guarantee equality.

OK. I got it. I solved this by saving timestamp. Thanks for the reason.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants