[ZEPPELIN-6483] Format HDFS modification time in GMT to match the printed label

[dev-donghwan]

What is this PR for?

In the HDFS file interpreter, listOne() appends a hard-coded GMT label to the
modification time, but listDate() formats the timestamp using the JVM default
time zone. On any server not running in UTC, the displayed value does not match
the label (e.g. a file modified at 2015-08-02 20:43 GMT is shown as
2015-08-03 05:43GMT on a KST server).

This PR sets the formatter's time zone to GMT in listDate() so the rendered
value matches the existing label.

Why format in GMT (option A) rather than keep local time and fix the label (option B):

• modificationTime is an absolute epoch value, so the time zone is only a
  display choice. Formatting in GMT keeps the output identical regardless of the
  host/JVM default zone and consistent with the label already printed.
• Showing the interpreter JVM's local time would be ambiguous in shared HDFS /
  remote-interpreter, multi-user setups ("whose local time?"), and the output
  would vary per deployment, making it harder to reproduce and test.

What type of PR is it?

Bug Fix

Todos

• - Format the modification time in GMT in listDate()
• - Add a regression test that runs under a non-UTC default zone (Asia/Seoul) and asserts the value is rendered in GMT to match the label

What is the Jira issue?

• https://issues.apache.org/jira/browse/ZEPPELIN-6483

How should this be tested?

• ./mvnw test -pl file -Dtest=HDFSFileInterpreterTest
• The new test testListDateFormatsInGmtToMatchLabel pins a known modificationTime (1438548219672 = 2015-08-02 20:43 GMT) under an Asia/Seoul default zone and asserts the output contains 2015-08-02 20:43GMT.

Screenshots (if appropriate)

N/A

Questions:

• Does the license files need to update? No
• Is there breaking changes for older versions? No — display-only change; on non-UTC servers the shown value changes, but it now correctly matches the label
• Does this needs documentation? No

[tbonelee]

LGTM.

Verified locally with the mock WebHDFS interpreter under an Asia/Seoul default zone: the
/app-logs entry goes from 2015-08-03 05:43GMT to 2015-08-02 20:43GMT, which is what
modificationTime 1438548219672 actually is in GMT. Reverting only the listDate() change
makes the new test fail, so it pins the regression rather than just asserting current
behaviour. Formatting in GMT also matches existing practice here, e.g. KerberosRealm uses
the same SimpleDateFormat + setTimeZone(TimeZone.getTimeZone("GMT")) pattern.

One non-blocking nit, fine to leave for a follow-up: new SimpleDateFormat(pattern) still
takes its calendar and digits from the JVM default locale, so the same class of environment
dependence survives. Same pattern, same GMT zone, only the default locale changed:

en-US                  2015-08-02 20:43
th-TH                  2558-08-02 20:43      (Buddhist calendar)
ja-JP-u-ca-japanese    27-08-02 20:43        (Japanese era)
ar-SA                  ٢٠١٥-٠٨-٠٢ ٢٠:٤٣      (Arabic-Indic digits)

new SimpleDateFormat("yyyy-MM-dd HH:mm", Locale.ROOT) closes that path too. Such JVM locales
are far rarer than non-UTC zones, so it is not a blocker.

[tbonelee]

Merged into master