Any difference between java.time.Clock.systemDefaultZone().getZone() vs java.util.TimeZone.getDefault().toZoneId()? -
is there difference in between two, given both java.time.clock.systemdefaultzone().getzone() , java.util.timezone.getdefault().tozoneid() return same output.
for instance code
import java.time.clock; import java.util.timezone; public class main { public static void main(string[] args) { system.out.println("clock.systemdefaultzone().getzone() : " + clock.systemdefaultzone().getzone()); system.out.println("timezone.getdefault().tozoneid() : " + timezone.getdefault().tozoneid()); } } returns output
clock.systemdefaultzone().getzone() : europe/paris timezone.getdefault().tozoneid() : europe/paris
both returns jvm's default timezone (in end, clock calls timezone.getdefault(), explained in @kiskae's answer), it's not guaranteed calls always return same value everytime.
that's because default timezone can changed:
- the system jvm running can change configuration. in windows machines, example, information read registry, while in linux gets
/etc/localtime(usually link specific file in/usr/share/zoneinfo) or similar folder (it can vary in each version/distribution), or settingtzenvironment variable. if system configuration changes , jvm restarted, code starts returning different values - the jvm can configured use different timezone, regardless of os's config. 1 example when maintanance/infrastructure team changes configuration (on purpose or accident, , without telling developers...) , code doesn't return same values anymore (and depends on timezone break)
your application (or application running same jvm) calls
timezone.setdefault()method. affect applications running in same jvm, at runtime, if run code:timezone.setdefault(timezone.gettimezone("europe/london")); system.out.println(zoneid.systemdefault()); timezone.setdefault(timezone.gettimezone("america/new_york")); system.out.println(zoneid.systemdefault()); timezone.setdefault(timezone.gettimezone("utc")); system.out.println(zoneid.systemdefault());
the output be:
europe/london
america/new_york
utc
note how default timezone changed @ runtime, , subsequent calls affected. same happen if call clock.systemdefaultzone().getzone() or timezone.getdefault().tozoneid(), because both uses default timezone.
as changes jvm's default timezone, applications running in same jvm affected it. might lead unexpected errors hard debug.
although methods use default timezone convenient, must check how code depends on , how can affected if zone changes.
if don't want depend on default, ideal use specific timezone, such zoneid.of("europe/paris"). prefer iana timezones names (always in format region/city, america/new_york or europe/paris). avoid using short abbreviations (like cet or cest) because ambiguous , not standard.
you can list of available timezones (and choose 1 fits best system) calling zoneid.getavailablezoneids().
Comments
Post a Comment