[foreign] test_time timezone trouble (TZ)
Jonathan Gibbons
jonathan.gibbons at oracle.com
Sat Sep 22 00:05:32 UTC 2018
I'm pleased that you found an even simpler solution to your problem.
Thanks for the note about TestNG.
-- Jon
On 09/21/2018 05:03 PM, Jorn Vernee wrote:
> Hey Jon,
>
> One of the other panama guys suggested to just drop the localtime()
> test and call gmtime() instead, which does not have the environment
> variable dependency. We currently have the luxury to do that, but the
> future might be different, so thanks for the RFE.
>
> FWIW the file in question [1] is using the '@run testng' action tag,
> so the option would need to be added there as well I guess.
>
> Jorn
>
> [1] :
> http://hg.openjdk.java.net/panama/dev/file/01ecea66dd99/test/jdk/java/foreign/StdLibTest.java
>
> Jonathan Gibbons schreef op 2018-09-22 01:30:
>> Jorn,
>>
>> Yes, short term, I would recommend option 2 as the way to go. There
>> should be examples to copy, and if you want to get cute and avoid
>> another source file, your test could have a main program that checks
>> if TZ is set, and if so, it re-execs itself without TZ.
>>
>> Long term, I think the right way to handle this would be either as an
>> option or an argument on the "@run main" and "@run shell" action tags.
>>
>> Neither are great, syntax-wise, but either would be good enough for
>> your specific case:
>>
>> For example,
>>
>> main[/fail][/manual][/othervm][/policy=<file>][/secure=<class>]
>> [/timeout=<seconds>][/e:NAME=VALUE]* <vm-opt>* <class> <arg>*
>>
>> main[/fail][/manual][/othervm][/policy=<file>][/secure=<class>]
>> [/timeout=<seconds>] [NAME=VALUE]* <vm-opt>* <class> <arg>*
>>
>> I'll file an RFE for jtreg.
>>
>> -- Jon
>>
>> On 09/21/2018 04:18 PM, Jorn Vernee wrote:
>>
>>> Hey Jon,
>>>
>>> Thanks for the suggestions (and thank you Michel for forwarding!).
>>>
>>> I will go with option 2 I think. I'm running the tests through `make
>>> test`, so I'm not sure how I would use the command-line flag, but
>>> setting a flag all the time is just what I'm trying to avoid any
>>> ways :) It doesn't look like there is a way to pass jtreg options
>>> from the test file itself? (maybe something like `@params "-eTZ="`).
>>>
>>>
>>> The test is calling a C standard library function, so that is to
>>> blame for the environment variable dependency.
>>>
>>> Thanks,
>>> Jorn
>>>
>>> Jonathan Gibbons schreef op 2018-09-21 23:29:
>>> Jorn,
>>>
>>> There is only limited amount of support for setting env variables in
>>>
>>> jtreg tests, because at least in the
>>> early releases of JDK, the use of environment variables was
>>> discouraged.
>>>
>>> Using `@run shell unsettz.sh` will not have the desired effect
>>> because
>>> it will only affect the shell
>>> that is created to run your shell script, and will not have a
>>> persistent environment on any other
>>> process.
>>>
>>> If you don't mind always setting a command-line option, you might
>>> try
>>> using `-eTZ=` on the jtreg
>>> command-line, which will unset TZ for all tests, although it would
>>> be
>>> more accurate to say that
>>> it will not set it for any tests.
>>>
>>> The only way to change the setting of TZ for any specific test will
>>> be
>>> to do one of the
>>> following:
>>>
>>> 1. Write the test as a shell script that unsets TZ and then runs any
>>>
>>> Java code, using various
>>> shell environment variables that will be available; these
>>> generally begin with "TEST".
>>>
>>> 2. Write the test as a Java program that execs a child process to
>>> run
>>> Java, with the exact set
>>> of environment variables you want to pass in. There are system
>>> properties that identify
>>> the test JDK, test class path and so on; these generally begin
>>> with "test.".
>>>
>>> These days, writing shell tests is generally discouraged, because it
>>>
>>> is notoriously difficult to get it
>>> right on all relevant platforms, and because these days, it is
>>> reasonably easy to use either
>>> the Java SE Process[Builder] API or test library API to invoke java.
>>>
>>>
>>> Hope that helps; if you have follow-up questions, please cc: me
>>> directly or use one of the jtreg-* aliases,
>>> since I am not on the panama-dev list.
>>>
>>> -- Jon
>>>
>>> On 09/21/2018 02:12 PM, Michel Trudeau wrote:
>>> [adding jtreg mailing list to seek out answer about jtreg and TZ on
>>> Windows]
>>>
>>> On Sep 21, 2018, at 12:44 PM, Jorn Vernee <jbvernee at xs4all.nl>
>>> wrote:
>>>
>>> Hello guys,
>>>
>>> I was running into a problem with the test_time test in StdLibTest.
>>> The generator for test values was apparently generating invalid
>>> values. After fixing that, all the test iterations were failing
>>> because the hours were off by one (the output of
>>> LocalDateTime.getHours() is being compared to the output of
>>> localtime().hour()). Good thing somebody else on the internet seems
>>> to have had the same problem [1]. TL;DR when using the MSVC version
>>> of localtime, and when running in cygwin, the function tries to
>>> interpret the TZ environment variable, but since that has a unix
>>> format (courtesy of cygwin), the interpretation fails and defaults
>>> to GMT. When TZ is not set, it defaults to the system default
>>> timezone, which is also what's being tested against.
>>>
>>> I can get the tests to pass by using `unset TZ` in the cygwin
>>> terminal before running them, but I'd have to do that every time I
>>> reboot it. I was trying to unset TZ automatically by using jtreq
>>> `@run shell unsettz.sh` where unsettz.sh is a file containing just
>>> the command `unset TZ`. It seems to be running successfully
>>> according to the test output:
>>>
>>> ACTION: shell -- Passed. Execution successful
>>> REASON: User specified action: run shell unsettz.sh
>>> TIME: 0.126 seconds
>>> messages:
>>> command: shell unsettz.sh
>>> reason: User specified action: run shell unsettz.sh
>>> elapsed time (seconds): 0.126
>>> STDOUT:
>>> STDERR:
>>>
>>> But it doesn't seem to affect the tests itself, and they still fail
>>> (still off by 1 hour).
>>>
>>> I was wondering if there is a way to let jtreg control environment
>>> variables? Or maybe you can suggest a different solution?
>>>
>>> The jtreg guide [2] mentions that TZ will be propagated from Windows
>>> 'if set', but I need it to be not set, or automatically set to the
>>> system's default time zone (by default it's blank).
>>>
>>> (other than that, tests are looking good: `passed: 24; failed: 4;
>>> error: 1`. I just need to fix structs by value, which on Windows
>>> cheats and just passes a pointer. 2 failing tests are from jextract
>>> missing)
>>>
>>> Thanks,
>>> Jorn
>>>
>>> [1] : https://stackoverflow.com/q/11655003
>>> [2] : http://openjdk.java.net/jtreg/tag-spec.html
More information about the jtreg-use
mailing list