RFR: 8250636: iso8601_time returns incorrect offset part on MacOS
Doerr, Martin
martin.doerr at sap.com
Mon Aug 10 19:20:32 UTC 2020
Hi,
unfortunately, tm_gmtoff seems to be a BSD and GNU extension.
It's not POSIX and doesn't build on AIX:
os.cpp:163:34: error: no member named 'tm_gmtoff' in 'tm'
We'll need a follow up fix.
Best regards,
Martin
> -----Original Message-----
> From: hotspot-runtime-dev <hotspot-runtime-dev-retn at openjdk.java.net>
> On Behalf Of gerard ziemski
> Sent: Dienstag, 4. August 2020 19:02
> To: Dmitry Cherepanov <dcherepanov at azul.com>; David Holmes
> <david.holmes at oracle.com>; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR: 8250636: iso8601_time returns incorrect offset part on
> MacOS
>
> Looks great!
>
> On 8/4/20 4:57 AM, Dmitry Cherepanov wrote:
> > Hi David,
> >
> > On 03.08.2020 10:53, David Holmes wrote:
> >> Hi Dmitry,
> >>
> >> On 31/07/2020 8:29 pm, Dmitry Cherepanov wrote:
> >>> Hi Gerard,
> >>>
> >>> Thanks for reviewing this, moving the logic of get_timezone to
> >>> iso8601_time looks good to me too.
> >>> Here's an updated webrev
> >>> http://cr.openjdk.java.net/~dcherepanov/8250636/webrev.v4/
> >> This version also looks good to me. But now I see all the code clearly in
> one place I have to wonder why we are not using tm_gmtoff on all platforms
> except Windows? That would simplify the logic even further.
> >>
> >> That goes beyond fixing the current actual bug though so I'll leave that
> choice to you.
> > Thanks for the suggestion. This change would not work on Solaris. But given
> the removal of Solaris port, I also see no other reasons why not to use
> tm_gmtoff on platforms except Windows.
> >
> > Updated webrev:
> http://cr.openjdk.java.net/~dcherepanov/8250636/webrev.v5/
> > Jdk-submit testing passed with this change
> >
> > Thanks,
> >
> > Dmitry
> >
More information about the hotspot-runtime-dev
mailing list