nate-dev commented on PR #55:
URL: https://github.com/apache/velocity-engine/pull/55#issuecomment-2453237026
The easiest way to reproduce the issue is to run the test on a machine that
is not in the GMT+1 time zone (Central European Time).
For example if I run the test in Seattle, it fails with the following error:
Velocity952TestCase.testEnd2End:93->BaseTestCase.assertEvalEquals:207->BaseTestCase.assertEvalEquals:216
expected:<[36]00000> but was:<[-288]00000>.
Alternatively, you can simulate running the test in another time zone by
adding the following to the velocity-engine-core pom.xml file, under
/project/build/plugins/plugin[6]/configuration/systemProperties:
```
<property>
<name>user.timezone</name>
<value>America/Los_Angeles</value>
</property>
```
That will reproduce the issue.
The root cause is: the java.util.TimeZone.getDefault(..) method returns the
default time zone of the JVM. See
[https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/TimeZone.html#getDefault()](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/TimeZone.html#getDefault()).
The value depends on where the machine running the tests is located.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org
