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
Post a Comment