You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+29-5Lines changed: 29 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1388,6 +1388,8 @@ Here is how GRDB supports the various [date formats](https://www.sqlite.org/lang
1388
1388
1389
1389
³ GRDB 2+ interprets numerical values as timestamps that fuel `Date(timeIntervalSince1970:)`. Previous GRDB versions used to interpret numbers as [julian days](https://en.wikipedia.org/wiki/Julian_day). Julian days are still supported, with the `Date(julianDay:)` initializer.
1390
1390
1391
+
>:warning:**Warning**: the range of valid years in the SQLite date formats is0000-9999. You will need to pick another date format when your application needs to process years outside of this range. See the following chapters.
1392
+
1391
1393
1392
1394
#### Date
1393
1395
@@ -1410,19 +1412,39 @@ Dates are stored using the format "YYYY-MM-DD HH:MM:SS.SSS" in the UTC time zone
1410
1412
>-Comparable with the SQLite keyword CURRENT_TIMESTAMP (`WHERE date > CURRENT_TIMESTAMP` works)
1411
1413
>- Able to feed [SQLite date & time functions](https://www.sqlite.org/lang_datefunc.html)
1412
1414
>- Precise enough
1415
+
>
1416
+
>:warning:**Warning**: the range of valid years in the SQLite date format is0000-9999. You will experience problems with years outside of this range, such as decoding errors, or invalid date computations with [SQLite date & time functions](https://www.sqlite.org/lang_datefunc.html).
1417
+
1418
+
Some applications may prefer another date format:
1419
+
1420
+
- Some may prefer ISO-8601, with a `T` separator.
1421
+
- Some may prefer ISO-8601, with a time zone.
1422
+
- Some may need to store years beyond the 0000-9999 range.
1423
+
- Some may need sub-millisecond precision.
1424
+
- Some may need exact `Date` roundtrip.
1425
+
- Etc.
1426
+
1427
+
**You should think twice before choosing a different date format:**
1413
1428
1414
-
When the default format does not fit your needs, customize date conversions. For example:
1429
+
- ISO-8601is about *exchange and communication*, when SQLite is about *storage and data manipulation*. Sharing the same representation in your database and in JSON files only provides a superficial convenience, and should be the least of your priorities. Don't store dates as ISO-8601 without understanding what you lose. For example, ISO-8601 time zones forbid database-level date comparison.
1430
+
- Sub-millisecond precision and exact `Date` roundtrip are not as obvious needs as it seems at first sight. Dates generally don't precisely roundtrip as soon as they leave your application anyway, because the other systems your app communicates with use their own date representation (the Android version of your app, the server your application is talking to, etc.) On top of that, `Date` comparison is at least as hard and nasty as [floating point comparison](https://www.google.com/search?q=floating+point+comparison+is+hard).
1431
+
1432
+
The customization of date format is explicit. For example:
1415
1433
1416
1434
```swift
1435
+
let date =Date()
1436
+
let timeInterval = date.timeIntervalSinceReferenceDate
1417
1437
try db.execute(
1418
1438
sql: "INSERT INTO player (creationDate, ...) VALUES (?, ...)",
let creationDate =Date(timeIntervalSinceReferenceDate: row["creationDate"])
1441
+
iflet row =try Row.fetchOne(db, ...) {
1442
+
let timeInterval: TimeInterval = row["creationDate"]
1443
+
let creationDate =Date(timeIntervalSinceReferenceDate: timeInterval)
1444
+
}
1423
1445
```
1424
1446
1425
-
See [Codable Records] for more date customization options.
1447
+
See also [Codable Records] for more date customization options, and [DatabaseValueConvertible](#custom-value-types) if you want to define a Date-wrapping type with customized database representation.
1426
1448
1427
1449
1428
1450
#### DateComponents
@@ -1431,6 +1453,8 @@ DateComponents is indirectly supported, through the **DatabaseDateComponents** h
1431
1453
1432
1454
DatabaseDateComponents reads date components from all [date formats supported by SQLite](https://www.sqlite.org/lang_datefunc.html), and stores them in the format of your choice, from HH:MM to YYYY-MM-DD HH:MM:SS.SSS.
1433
1455
1456
+
>:warning:**Warning**: the range of valid years is0000-9999. You will experience problems with years outside of this range, such as decoding errors, or invalid date computations with [SQLite date & time functions](https://www.sqlite.org/lang_datefunc.html). See [Date](#date) for more information.
1457
+
1434
1458
DatabaseDateComponents can be stored and fetched from the database just like other [values](#values):
0 commit comments