[
https://issues.apache.org/jira/browse/SPARK-15723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15315898#comment-15315898
]
Sean Owen commented on SPARK-15723:
-----------------------------------
Yeah I get the ambiguity problem. OK, so you're saying it doesn't help to set
the time zone on the SimpleDateFormat, that the disambiguation is always
relative to the machine's time zone and not what is configured for the
SimpleDateFormat?
I tried this FWIW and it gave the 'right' answer according to the current test,
not sure what's different:
{code}
$ scala -J-Duser.timezone="Australia/Sydney"
scala> System.getProperty("user.timezone")
res0: String = Australia/Sydney
...
scala> val sdf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSz")
sdf: java.text.SimpleDateFormat = java.text.SimpleDateFormat@8a9df61b
scala> sdf.parse("2015-02-20T17:21:17.190EST").getTime
res1: Long = 1424470877190
{code}
Anyway I think just patching up the test is OK for now.
> SimpleDateParamSuite test is locale-fragile and relies on deprecated short TZ
> name
> ----------------------------------------------------------------------------------
>
> Key: SPARK-15723
> URL: https://issues.apache.org/jira/browse/SPARK-15723
> Project: Spark
> Issue Type: Bug
> Components: Spark Core
> Affects Versions: 1.6.1
> Reporter: Brett Randall
> Priority: Minor
> Labels: test
>
> {{org.apache.spark.status.api.v1.SimpleDateParamSuite}} has this assertion:
> {code}
> new SimpleDateParam("2015-02-20T17:21:17.190EST").timestamp should be
> (1424470877190L)
> {code}
> This test is fragile and fails when executing in an environment where the
> local default timezone causes {{EST}} to be interpreted as something other
> than US Eastern Standard Time. If your local timezone is
> {{Australia/Sydney}}, then {{EST}} equates to {{GMT+10}} and you will get:
> {noformat}
> date parsing *** FAILED ***
> 1424413277190 was not equal to 1424470877190 (SimpleDateParamSuite.scala:29)
> {noformat}
> In short, {{SimpleDateFormat}} is sensitive to the local default {{TimeZone}}
> when interpreting short zone names. According to the {{TimeZone}} javadoc,
> they ought not be used:
> {quote}
> Three-letter time zone IDs
> For compatibility with JDK 1.1.x, some other three-letter time zone IDs (such
> as "PST", "CTT", "AST") are also supported. However, their use is deprecated
> because the same abbreviation is often used for multiple time zones (for
> example, "CST" could be U.S. "Central Standard Time" and "China Standard
> Time"), and the Java platform can then only recognize one of them.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
