From nobody Wed Feb 14 21:04:32 2024 X-Original-To: freebsd-java@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TZrKt0xjPz53PGN for ; Wed, 14 Feb 2024 21:04:34 +0000 (UTC) (envelope-from csab6597@gmail.com) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TZrKs60Sgz4vcX for ; Wed, 14 Feb 2024 21:04:33 +0000 (UTC) (envelope-from csab6597@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a2f79e79f0cso16755466b.2 for ; Wed, 14 Feb 2024 13:04:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707944672; x=1708549472; darn=freebsd.org; h=content-language:thread-index:mime-version:message-id:date:subject :in-reply-to:references:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=RrAHw/ljMlI1yHxo6WgagCbKNaS6AFQNNsRMsBIv/ok=; b=R9Cg7YXMk5xDv0X+24a7hDVBF0uebqs+xjw7uRuEc1Jn12ILcOh+kww41IVY9PDVcO T239xEFy+G7P5ZcLwBU42lhYL19DdaCPwHKK7ThpaBKmcx3gZPtIDw22d9qWV5j6+YtL u/yepOAe26L4qQRRhzEUWkNo2TT8RR/A3NxFEv+9/19/93nVw2szHNrDBYhUybmOxWIK Wp4rnrl3J3CLmwBH1dxsZAAzK7qerv9QAA4k8dUcPUon5GCnynglTOxL8OqEFpNBkgDz 38NF1/ylw3DjFTfUPcux+uFMxvtKHzUMgMD7sEh6m5z7yV/iYjRgvJ6v4ZHqT1ZUAjcM 6N1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707944672; x=1708549472; h=content-language:thread-index:mime-version:message-id:date:subject :in-reply-to:references:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RrAHw/ljMlI1yHxo6WgagCbKNaS6AFQNNsRMsBIv/ok=; b=XEi3itM53ikrErfX19MP93qyhgB2M6c7lzcRPH+S3SrC8gMsmsEeh7o04FEfSdAmy5 nWn6KNadqq0qnXC0vlkMR9eLGJEBA9YtN7L09oAQazL3qJR60KRPaCQUsc3tEC8ClRWU wTu+oR1Gt9bTmxnSc9eVCYemNQ0PgPEJbneC/ng8REVXcn/btrLAX/Zpmn06fd5TxmW2 Yxeah1LNciFySGt3Jy8TNMqF8rkF9VyeVhmyaYRpHmHxUjw22OddRAtPMFKIrVDzZkbT vYWi6hMDChAJ4jarQUK9dnZ/Jfu+tBjYQKT39OdypnR2KVV6gMsUvjU2M+AiaMBdmqEb qnxA== X-Gm-Message-State: AOJu0YwEixwdNyrdrOpcLHZEMGzXaBsDEe3UiRHCh1XP7BaO8SyUuoD0 DNdfvPSI8x/PmniOSvSM/bqVhz4sZmwSaH4mzx0IpjNHlk66NLHvHhHjLE10 X-Google-Smtp-Source: AGHT+IGPqnG87RLURQuRDwjFAuJB5WtLHqK5piDdCsZNmuBVGD3RnFw/Lw1D21Lzu9vIqZTJXKjJIQ== X-Received: by 2002:a17:906:374a:b0:a3d:2637:b713 with SMTP id e10-20020a170906374a00b00a3d2637b713mr3169663ejc.54.1707944671647; Wed, 14 Feb 2024 13:04:31 -0800 (PST) Received: from RAY ([2001:871:24b:d5c7:4906:452:d5c2:7dfe]) by smtp.gmail.com with ESMTPSA id xa17-20020a170907b9d100b00a3d5fc424a0sm617841ejc.194.2024.02.14.13.04.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Feb 2024 13:04:31 -0800 (PST) From: To: "'Michael Zhilin'" Cc: References: <004901da5c6b$a36b1150$ea4133f0$@gmail.com> In-Reply-To: Subject: AW: Issue: Java does not honor timezone setting Date: Wed, 14 Feb 2024 22:04:32 +0100 Message-ID: <003a01da5f89$68dd1ad0$3a975070$@gmail.com> List-Id: Porting Java to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-java List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-java@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003B_01DA5F91.CAA24620" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQI7+4bMmd0f7Vc1VpHka6TWxqPodAFbtnISsDwy0lA= Content-Language: de-at X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4TZrKs60Sgz4vcX X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated This is a multipart message in MIME format. ------=_NextPart_000_003B_01DA5F91.CAA24620 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Michael, =20 I used tzsetup and selected Europe/Austria. After doing so I now get the = correct time zone and therefore time value in java. =20 # date Wed Feb 14 21:21:06 CET 2024 =20 # jshell | Welcome to JShell =E2=80=93 Version 19.0.2 | For an introduction type: /help intro =20 jshell> java.time.ZonedDateTime.now() &1 =3D=3D> 2024-02-14T21_21_36.093531195+01:00[Europe/Vienna] =20 Now the situation is like * When I change the TrueNAS systemwide timezone, which was always set to = Europe/Vienna by the way, that is indeed reflected through the = =E2=80=9Cdate=E2=80=9D command (but only after a system restart). But = such a change is not adopted in Java. * Whereas the other way round, any change through tzsetup is indeed = reflected in Java as well as in =E2=80=9Cdate=E2=80=9D =20 At first I put up the following thread in the TrueNAS forum = = https://www.truenas.com/community/threads/java-reporting-wrong-time-zone-= in-jail.116366/ from where I was pointed to you. Do you think I should = now point back to some TrueNAS configuration issue? =20 Greets, Rainer =20 =20 =20 Von: Michael Zhilin =20 Gesendet: Mittwoch, 14. Februar 2024 16:46 An: csab6597@gmail.com Cc: freebsd-java@freebsd.org Betreff: Re: Issue: Java does not honor timezone setting =20 Hi, =20 I've tried to use /usr/share/zoneinfo/CET as /etc/localtime and it seems = java can't identify TZ correctly. But in case of particular country's TZ, it works fine: =20 # tzsetup root@tamagawa /usr/share/zoneinfo # date Wed Feb 14 16:40:48 CET 2024 root@tamagawa /usr/share/zoneinfo # export JAVA_VERSION=3D17 root@tamagawa /usr/share/zoneinfo # jshell | Welcome to JShell -- Version 17.0.9 | For an introduction type: /help intro jshell> java.time.ZonedDateTime.now() $1 =3D=3D> 2024-02-14T16:41:13.106408203+01:00[Europe/Andorra] =20 I have no access to TrueNAS & jdk19, could you please try to specify the = country's TZ by tzsetup and check tz in java? =20 Thanks! =20 =20 On Sun, Feb 11, 2024 at 12:53=E2=80=AFAM > wrote: Hi there, =20 I am using TrueNAS Core TrueNAS-13.0-U6.1 where in a jail I installed = jdk 19. In the shell I get =20 # java -version openjdk version "19.0.2" 2023-01-17 OpenJDK Runtime Environment (build 19.0.2+7-1) OpenJDK 64-Bit Server VM (build 19.0.2+7-1, mixed mode, sharing) =20 The issue I encountered is that java does not honor the timezone I have = set in TrueNAS. When using the builtin command in the TrueNAS shell I can see =20 # date Sat Feb 10 10:36:35 CET 2024 =20 So that command reports CET timezone which is in fact what it should be, = what is set in TrueNAS system configuration But inside java, for a test just using jshell, then java will report GMT = which means java is ignoring the timezone setting and thus giving an = offset to the actual time =20 # jshell | Welcome to JShell -- Version 19.0.2 | For an introduction type: /help intro =20 jshell> java.time.ZonedDateTime.now() $3 =3D=3D> 2024-02-10T09:38:12.192401862Z[GMT] =20 jshell> java.time.LocalDateTime.now() $1 =3D=3D> 2024-02-10T09:38:12.192401862Z =20 =20 Also tested in Windows and Ubuntu where Java will indeed report the = correct timezone =20 Greets, Rainer=20 ------=_NextPart_000_003B_01DA5F91.CAA24620 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Michael,

 

I used = tzsetup and selected Europe/Austria. After doing so I now get the = correct time zone and therefore time value in = java.

 

# date

Wed Feb 14 21:21:06 CET = 2024

 

# jshell

| =C2=A0Welcome to JShell = =E2=80=93 Version 19.0.2

|=C2=A0 For an introduction type: = /help intro

 

jshell> = java.time.ZonedDateTime.now()

&1 =3D=3D> = 2024-02-14T21_21_36.093531195+01:00[Europe/Vienna]

 

Now the = situation is like

  • When I change the TrueNAS = systemwide timezone, which was always set to Europe/Vienna by the way, = that is indeed reflected through the =E2=80=9Cdate=E2=80=9D command (but = only after a system restart). But such a change is not adopted in = Java.
  • Whereas the other way round, any = change through tzsetup is indeed reflected in Java as well as in = =E2=80=9Cdate=E2=80=9D

 

At first = I put up the following thread in the TrueNAS forum https://www.truenas.com/community/threads/java-reporting-wro= ng-time-zone-in-jail.116366/ from where I was pointed = to you. Do you think I should now point back to some TrueNAS = configuration issue?

 

Greets, = Rainer

 

 

 

Von: Michael = Zhilin <mizhka@gmail.com>
Gesendet: Mittwoch, 14. = Februar 2024 16:46
An: csab6597@gmail.com
Cc: = freebsd-java@freebsd.org
Betreff: Re: Issue: Java does not = honor timezone setting

 

Hi,

 

I've tried to use /usr/share/zoneinfo/CET as = /etc/localtime and it seems java can't identify TZ = correctly.

But in case of = particular country's TZ, it works fine:

 

 # tzsetup
root@tamagawa = /usr/share/zoneinfo
 # date
Wed Feb 14 16:40:48 CET = 2024
root@tamagawa /usr/share/zoneinfo
 # export = JAVA_VERSION=3D17
root@tamagawa /usr/share/zoneinfo
 # = jshell
|  Welcome to JShell -- Version 17.0.9
|  For an = introduction type: /help intro

jshell> = java.time.ZonedDateTime.now()
$1 =3D=3D> = 2024-02-14T16:41:13.106408203+01:00[Europe/Andorra]

<= div>

 

I have no access to TrueNAS & jdk19, could you = please try to specify the country's TZ by tzsetup and check tz in = java?

 

Thanks!

 

 

On = Sun, Feb 11, 2024 at 12:53=E2=80=AFAM <csab6597@gmail.com> = wrote:

Hi = there,

 

I am using TrueNAS Core = TrueNAS-13.0-U6.1 where in a jail I installed jdk 19. In the shell I = get

 

# java -version

openjdk version "19.0.2" = 2023-01-17

OpenJDK Runtime Environment (build = 19.0.2+7-1)

OpenJDK 64-Bit Server VM (build 19.0.2+7-1, mixed = mode, sharing)

 

The issue I encountered is that = java does not honor the timezone I have set in = TrueNAS.

When using the builtin command =  in the TrueNAS shell I can see

 

# =
date
Sat Feb 10 10:36:35 CET =
2024

 

So that command reports CET = timezone which is in fact what it should be, what is set in TrueNAS = system configuration

But inside java, for a test just = using jshell, then java will report GMT which means java is ignoring the = timezone setting and thus giving an offset to the actual = time

 

# =
jshell
|  Welcome to JShell -- Version =
19.0.2
|  For an introduction type: =
/help intro
 
jshell> =
java.time.ZonedDateTime.now()
$3 =
=3D=3D> =
2024-02-10T09:38:12.192401862Z[GMT]
 
jshell> =
java.time.LocalDateTime.now()
$1 =
=3D=3D> 2024-02-10T09:38:12.192401862Z

 

 

Also tested in Windows and = Ubuntu where Java will indeed report the correct = timezone

 

Greets, Rainer =

<= /html> ------=_NextPart_000_003B_01DA5F91.CAA24620--