java-time

问题 Is there an official list of zone names that are used for the following: zoneId = ZoneId.of("America/New_York") Or is it possible for java.time.ZoneId to generate the list itself that I can use? I'm using this to convert an Instant to a string representation of time like: ZoneDateTime.ofInstant(instant, zoneId).format(DateTimeFormatter.ofPattern("...")) 回答1: Just use the getAvailableZoneIds method. Gets the set of available zone IDs. This set includes the string form of all available region

问题 To get a ZoneId it goes like: ZoneId.of("America/Sao_Paulo"); or ZoneId.of(ZoneId.SHORT_IDS.get("BET")); Why would be the reason for not existing an Enum of such values, like: ZoneId.of(ZoneIds.AMERICA_SAO_PAULO); which seems less error-prone and a lot more auto-complete friendly? 回答1: I believe it's because the list of all possible timezones names can change regardless of Java version. Timezone information comes with Java installation (usually in the folder <java-home>/lib/zi , or in jre/lib

问题 Convert LocalDateTime to LocalDateTime in UTC. LocalDateTime convertToUtc(LocalDateTime date) { //do conversion } I searched over net. But did not get a solution 回答1: I personally prefer LocalDateTime.now(ZoneOffset.UTC); as it is the most readable option. 回答2: There is an even simpler way LocalDateTime.now(Clock.systemUTC()) 回答3: LocalDateTime does not contain Zone information. ZonedDatetime does. If you want to convert LocalDateTime to UTC, you need to wrap by ZonedDateTime fist. You can

问题 Convert LocalDateTime to LocalDateTime in UTC. LocalDateTime convertToUtc(LocalDateTime date) { //do conversion } I searched over net. But did not get a solution 回答1: I personally prefer LocalDateTime.now(ZoneOffset.UTC); as it is the most readable option. 回答2: There is an even simpler way LocalDateTime.now(Clock.systemUTC()) 回答3: LocalDateTime does not contain Zone information. ZonedDatetime does. If you want to convert LocalDateTime to UTC, you need to wrap by ZonedDateTime fist. You can

问题 I am trying to rewrite below two lines of code from C# into Java. long ticks1970Onwards = new DateTime(1970, 1, 1, 0, 0, 0, 0, DateTimeKind.Utc).Ticks; long newTs = (DateTime.UtcNow.Ticks - ticks1970Onwards)/10000; I tried multiple ways , but I don't get the correct solution. ZonedDateTime dt1 = LocalDateTime.now().atZone(ZoneId.of("UTC")); ZonedDateTime dt2 = LocalDateTime.of(1901, 1, 1, 0, 0).atZone(ZoneId.of("UTC")); Duration duration2 = Duration.between(dt2, dt1); System.out.printf(

问题 When creating a new LocalDateTime using LocalDateTime.now() on my Mac and Windows machine i get a nano precision of 6 on my Mac and a nano precision of 3 on my Windows machine. Both are running jdk-1.8.0-172 . Is it possible to limit or increase the precision on one of the machines? And why is the precision actually different? 回答1: The precision is different because LocalDateTime.now() uses a system default Clock. Obtains the current date-time from the system clock in the default time-zone.

问题 When creating a new LocalDateTime using LocalDateTime.now() on my Mac and Windows machine i get a nano precision of 6 on my Mac and a nano precision of 3 on my Windows machine. Both are running jdk-1.8.0-172 . Is it possible to limit or increase the precision on one of the machines? And why is the precision actually different? 回答1: The precision is different because LocalDateTime.now() uses a system default Clock. Obtains the current date-time from the system clock in the default time-zone.

问题 When creating a new LocalDateTime using LocalDateTime.now() on my Mac and Windows machine i get a nano precision of 6 on my Mac and a nano precision of 3 on my Windows machine. Both are running jdk-1.8.0-172 . Is it possible to limit or increase the precision on one of the machines? And why is the precision actually different? 回答1: The precision is different because LocalDateTime.now() uses a system default Clock. Obtains the current date-time from the system clock in the default time-zone.

问题 When creating a new LocalDateTime using LocalDateTime.now() on my Mac and Windows machine i get a nano precision of 6 on my Mac and a nano precision of 3 on my Windows machine. Both are running jdk-1.8.0-172 . Is it possible to limit or increase the precision on one of the machines? And why is the precision actually different? 回答1: The precision is different because LocalDateTime.now() uses a system default Clock. Obtains the current date-time from the system clock in the default time-zone.

问题 When creating a new LocalDateTime using LocalDateTime.now() on my Mac and Windows machine i get a nano precision of 6 on my Mac and a nano precision of 3 on my Windows machine. Both are running jdk-1.8.0-172 . Is it possible to limit or increase the precision on one of the machines? And why is the precision actually different? 回答1: The precision is different because LocalDateTime.now() uses a system default Clock. Obtains the current date-time from the system clock in the default time-zone.