java - LocalDate inconsistency -


i trying produce date object (java.util.date) localdate object (java.time.localdate) in have following criteria:

  • allow parameter can subtract number of days date object
  • have date & time date , time in utc
  • have time @ beginning of day i.e. 00:00:00
  • the timezone stamp (i.e. cdt or utc) irrelevant remove string

to meet criteria, have created test program, getting interesting results when modify property of localdate. see code below:

  public static void main (string args[]) {     long processingdaysinpast = 0l;     localdate createddate1 = localdate.now(clock.systemutc()).minusdays(processingdaysinpast);     localdate createddate2 = localdate.now(clock.systemutc()).minusdays(processingdaysinpast);     system.out.println(createddate1);     system.out.println(createddate1.atstartofday().toinstant(zoneoffset.utc));     system.out.println(date.from(createddate1.atstartofday().toinstant(zoneoffset.utc)));     system.out.println((createddate2.atstartofday().atzone(zoneid.systemdefault()).toinstant()));     system.out.println(date.from(createddate2.atstartofday().atzone(zoneid.systemdefault()).toinstant())); } 

output:

 2017-08-14  2017-08-14t00:00:00z  sun aug 13 19:00:00 cdt 2017  2017-08-14  2017-08-14t05:00:00z  mon aug 14 00:00:00 cdt 2017 

when add value date.from(createddate1.atstartofday().toinstant(zoneoffset.utc)) expected output of date, 00:00:00 time field. however, if not add parameter, such as: date.from(createddate2.atstartofday().atzone(zoneid.systemdefault()).toinstant()) resulting day before , @ 19:00:00 why this?

my main goal able capture date object, current utc date, , time zeroed out (startofday).

when do:

createddate2.atstartofday().atzone(zoneid.systemdefault()) 

first, createddate2.atstartofday() returns localdatetime, equivalent 2017-08-14 @ midnight. localdatetime not timezone-aware.

when call atzone(zoneid.systemdefault()), creates zoneddatetime respective date (2017-08-14) , time (midnight) in system's default timezone (zoneid.systemdefault()). , in case, default timezone not utc (it's "cdt", it's getting midnight @ cdt - system.out.println(zoneid.systemdefault()) check default timezone is).

to date @ midnight in utc, can replace default zone (zoneid.systemdefault()) utc (zoneoffset.utc):

date.from(createddate2.atstartofday().atzone(zoneoffset.utc).toinstant()) 

or (a shorter version):

date.from(createddate2.atstartofday(zoneoffset.utc).toinstant()) 

of course can same way did createddate1:

date.from(createddate2.atstartofday().toinstant(zoneoffset.utc)) 

they're equivalent , result in midnight @ utc.


just quick note: short timezone names cdt or pst not real timezones.
api uses iana timezones names (always in format region/city, america/chicago or europe/berlin). avoid using 3-letter abbreviations (like cdt or pst) because ambiguous , not standard.

there lots of different timezones can use cdt abbreviation. happens because timezone set of different offsets region had, has , have during history. because many places uses cdt today, doesn't mean used in past @ same periods, nor it'll used in future. history differs, timezone created each region.


Comments

Popular posts from this blog

android - InAppBilling registering BroadcastReceiver in AndroidManifest -

python Tkinter Capturing keyboard events save as one single string -

sql server - Why does Linq-to-SQL add unnecessary COUNT()? -