On 9 October 2017 at 14:40, Claes Redestad <claes.redes...@oracle.com> wrote:
> In addition to being a cleanup, the move to use java.time did provide a
> speedup, however, which
> might become significant when loading lots of jar files.
>
> I've not found my notes on how big this speed-up was (I recall ~3x in
> micros), but if anyone has time
> to fix (and test) the overflows without reverting to java.util.Date then we
> might be able to keep most
> of that gain intact. This can of course be considered a follow-up, or
> ignored.
In theory, this code should be equivalent, although I've not tested it:
```
int year = (int) (((dtime >> 25) & 0x7f) + 1980);
int month = (int) ((dtime >> 21) & 0x0f);
int day = ((int) ((dtime >> 16) & 0x1f)) - 1;
int hour = (int) ((dtime >> 11) & 0x1f);
int min = (int) ((dtime >> 5) & 0x3f);
int sec = (int) ((dtime << 1) & 0x3e);
long secs = day * 86400 + hour * 3600 + min * 60 + sec;
LocalDateTime ldt = LocalDateTime.of(year, month, 1).plusSeconds(secs);
return TimeUnit.MILLISECONDS.convert(ldt.toEpochSecond(
ZoneId.systemDefault().getRules().getOffset(ldt)),
TimeUnit.SECONDS);
```
It could be further enhanced if the day was known to be in range, but
this code assumes that can't be guaranteed.
Another option would be to add a method `ofLenient(...)` to
`LocalDate`, `LocalTime`, `LocalDateTime` etc, as the problem is a
generally applicable one.
Stephen
