With these helpers on JS (browsers, node.js), we obtain an OffsetDateTime.now() equivalent (of course up to millisecond resolution due to JS nature) without the need to add tzdb. This unlocks all of {LocalDate, LocalDateTime, LocalTime, MonthDay, OffsetDateTime, OffsetTime, Year, YearMonth}.now() straightforward implementations in terms of the OffsetDateTime.now() instance. And only ZonedDateTime, which intuitively should be the only one that requires actual tz data is left with that need.
def utcOffsetSeconds(ms: Long) = -new Date(ms.toDouble).getTimezoneOffset().toInt * 60
def offsetDateTimeInDefaultTimeZone(instant: Instant) = instant.atOffset(ZoneOffset.ofTotalSeconds(utcOffsetSeconds(instant.toEpochMilli)))
def offsetDateTimeInDefaultTimeZoneNow() = offsetDateTimeInDefaultTimeZone(Instant.now())
What do you think about this?
With these helpers on JS (browsers, node.js), we obtain an OffsetDateTime.now() equivalent (of course up to millisecond resolution due to JS nature) without the need to add tzdb. This unlocks all of {LocalDate, LocalDateTime, LocalTime, MonthDay, OffsetDateTime, OffsetTime, Year, YearMonth}.now() straightforward implementations in terms of the OffsetDateTime.now() instance. And only ZonedDateTime, which intuitively should be the only one that requires actual tz data is left with that need.
What do you think about this?