@@ -312,18 +312,59 @@ less information, e.g. (assuming we're in UTC timezone):
312
312
=> #object[java.time.LocalTime 0x3a3cd6d5 " 01:00" ]
313
313
```
314
314
315
- Any date which can be converted to an instant, can also be converted to pre-Java
316
- 8 date types:
315
+ #### Legacy Date-Time Types
317
316
318
- ``` clj
319
- (to-java-date (zoned-date-time 2015 9 28 ))
317
+ Any date which can be converted to an instant, can also be converted to a
318
+ ` java.util.Date ` :
319
+
320
+ ``` clojure
321
+ (java-date (zoned-date-time 2015 9 28 ))
320
322
=> #inst " 2015-09-27T22:00:00.000-00:00"
321
323
322
- (to-sql-date (zoned-date-time 2015 9 28 ))
324
+ (java-date 50000 )
325
+ => #inst " 1970-01-01T00:00:50.000-00:00"
326
+ ```
327
+
328
+ An instance of ` java.util.Date ` serves the same purpose as the new
329
+ ` java.time.Instant ` . It's a machine timestamp which isn't aware of the
330
+ timezone. Please, do not get confused by the way it is printed by the Clojure
331
+ printer - the UTC timezone is applied during formatting.
332
+
333
+ Sometimes you'll have to work with the legacy ` java.sql.Date/Time/Timestamp `
334
+ types. The correspondence between the legacy types and the new Date-Time
335
+ entities is as follows:
336
+
337
+ * ` java.time.LocalDate ` - ` java.sql.Date `
338
+ * ` java.time.LocalDateTime ` - ` java.sql.Timestamp `
339
+ * ` java.time.LocalTime ` - ` java.sql.Time `
340
+
341
+ ``` clojure
342
+ (sql-date 2015 9 28 )
323
343
=> #inst " 2015-09-27T22:00:00.000-00:00"
324
344
325
- (to-sql-timestamp (zoned-date-time 2015 9 28 ))
326
- => #inst " 2015-09-27T22:00:00.000000000-00:00"
345
+ (sql-timestamp 2015 9 28 10 20 30 4000000 )
346
+ => #inst " 2015-09-28T09:20:30.004-00:00"
347
+
348
+ (sql-time 10 20 30 )
349
+ => #inst " 1970-01-01T09:20:30.000-00:00"
350
+ ```
351
+
352
+ The results of the above calls get printed as ` #inst ` because all of the
353
+ ` java.sql.Date/Time/Timestamp ` are subtypes of ` java.util.Date ` .
354
+ Coincidentally, this makes it impossible to plug the ` java.sql.* ` types into
355
+ the Clojure.Java-Time conversion graph.
356
+
357
+ Conversions to the legacy types also go the other way around:
358
+
359
+ ``` clojure
360
+ (j/local-date (j/sql-date 2015 9 28 ))
361
+ #object[java.time.LocalDate " 2015-09-28" ]
362
+
363
+ (j/local-date-time (j/sql-timestamp 2015 9 28 10 20 30 4000000 ))
364
+ #object[java.time.LocalDateTime " 2015-09-28T10:20:30.004" ]
365
+
366
+ (j/local-time (j/sql-time 10 20 30 ))
367
+ #object[java.time.LocalTime " 10:20:30" ]
327
368
```
328
369
329
370
#### Three-Ten Extra
@@ -335,7 +376,7 @@ project, you will get an `Interval`, `AmPm`, `DayOfMonth`, `DayOfYear`,
335
376
An interval can be constructed from two entities that can be converted to
336
377
instants:
337
378
338
- ``` clj
379
+ ``` clojure
339
380
(interval (offset-date-time 2015 1 1 ) (zoned-date-time 2016 1 1 ))
340
381
=> #<org.threeten.extra.Interval 2015 -01-01 T00:00:00Z/2016 -01-01 T00:00:00Z>
341
382
@@ -354,7 +395,7 @@ instants:
354
395
Bonus! if you have Joda Time on the classpath (either directly, or via
355
396
` clj-time ` ), you can seamlessly convert from Joda Time to Java Time types:
356
397
357
- ``` clj
398
+ ``` clojure
358
399
(java-time.repl/show-path org.joda.time.DateTime java.time.OffsetTime)
359
400
=> {:cost 2.0 ,
360
401
:path [[#<java_time.graph.Types@15e43 c24 [org.joda.time.DateTime]>
@@ -374,7 +415,7 @@ you to influence the date-times create using default constructors ala Joda's
374
415
` DateTimeUtils/setCurrentMillisSystem ` . Clojure.Java-Time tries to fix that with
375
416
the ` with-clock ` macro and the corresponding ` with-clock-fn ` function:
376
417
377
- ``` clj
418
+ ``` clojure
378
419
(zone-id )
379
420
=> #<java.time.ZoneRegion Europe/London>
380
421
@@ -391,7 +432,7 @@ Date-Time entities are composed of date fields, while Duration entities are
391
432
composed of time units. You can see all of the predefined fields and units
392
433
via the ` java-time.repl ` ns:
393
434
394
- ``` clj
435
+ ``` clojure
395
436
(java-time.repl/show-fields )
396
437
=> (:aligned-day-of-week-in-month
397
438
:aligned-day-of-week-in-year
@@ -402,7 +443,7 @@ via the `java-time.repl` ns:
402
443
...)
403
444
```
404
445
405
- ``` clj
446
+ ``` clojure
406
447
(java-time.repl/show-units )
407
448
=> (:centuries
408
449
:days
@@ -415,7 +456,7 @@ via the `java-time.repl` ns:
415
456
416
457
You can obtain any field/unit like this:
417
458
418
- ``` clj
459
+ ``` clojure
419
460
(field :year )
420
461
=> #object[java.time.temporal.ChronoField " Year" ]
421
462
@@ -428,7 +469,7 @@ You can obtain any field/unit like this:
428
469
429
470
You can obtain all of the fields/units of the temporal entity:
430
471
431
- ``` clj
472
+ ``` clojure
432
473
(fields (local-date ))
433
474
=> {:proleptic-month #object[java.time.temporal.ChronoField ...}
434
475
@@ -441,7 +482,7 @@ By themselves the fields and units aren't very interesting. You can get the
441
482
range of valid values for a field and a duration between two dates, but that's
442
483
about it:
443
484
444
- ```clj
485
+ ```clojure
445
486
(range (field :year ))
446
487
=> #object[java.time.temporal.ValueRange " -999999999 - 999999999" ]
447
488
@@ -458,7 +499,7 @@ are reasons for that which I feel are only valid in a statically-typed API like
458
499
Java's. In Clojure, properties allow expressing time entity modifications and
459
500
queries uniformly across all of the entity types.
460
501
461
- ```clj
502
+ ```clojure
462
503
(def prop (property (local-date 2015 2 28 ) :day-of-month ))
463
504
=> #java_time.temporal.TemporalFieldProperty{...}
464
505
@@ -496,7 +537,7 @@ Hopefully, the performance issue will be resolved in the future...
496
537
497
538
You can play with the conversion graph using the following helpers:
498
539
499
- ```clj
540
+ ```clojure
500
541
(java-time.repl/show-path org.joda.time.DateTime java.time.OffsetTime)
501
542
=> {:cost 2.0 ,
502
543
:path [[#<java_time.graph.Types@15e43 c24 [org.joda.time.DateTime]>
0 commit comments