【发布时间】：2016-05-18 19:36:36
【问题描述】：
我正在尝试将从 Windows 管理界面检索到的 DateTime 值转换为 Java (1.7) 日期；最终到自纪元以来的毫秒数。 format is specified here。
我尝试解析的一个示例是 20160513072950.782000-420，即 2016 年 5 月 13 日 07:29:50 加上 782 毫秒，在我的本地时区（-420 分钟 = UTC-7 小时）。小数点后的数字是小数秒；理论上最多 6 位微秒，但实际上只有前 4 位是非零的。
我最初尝试使用 SimpleDateFormat 进行解析，指定我想要解析的三位数毫秒：
SimpleDateFormat cimDateFormat = new SimpleDateFormat("yyyyMMddHHmmss.SSS");
Date date = cimDateFormat.parse(s, new ParsePosition(0));
我的理由是用SSS 指定毫秒的三位数字会停止解析。不幸的是，这不起作用。在上面的例子中添加了超过 782 毫秒。
我最终通过将字符串修剪为所需的字符来使其按需要工作：
SimpleDateFormat cimDateFormat = new SimpleDateFormat("yyyyMMddHHmmss.S");
Date date = cimDateFormat.parse(s.substring(0, 18), new ParsePosition(0));
在这种情况下，我只包含了一个 S 毫秒，但它解析了所有三个。
我在SimpleDateFormat javadoc 中找不到任何可以清楚地解释解析结束时发生的情况的内容。具体问题：
- 为什么在
SSS的情况下，它总是解析超过指定的位数？ - 为什么单个
S会解析所有 3 毫秒数字？ - 除了像我一样截断字符串之外，还有其他方法可以告诉
SimpleDateFormat在指定位置停止解析字符串吗？
【问题讨论】：
-
解析时，模式字母的数量会被忽略，除非需要分隔两个相邻的字段
-
@SotiriosDelimanolis 谢谢——回答了 1 和 2。现在对于 3，我可以在 SSS 之后添加一个“相邻字段”，上面写着“多余的字符，忽略”吗？
-
不忽略，不。这6个字符让我感到困惑。它们是小数秒吗？看起来不像，但为什么会有 6 位数字呢？为什么不崩溃到其他领域呢？
SimpleDateFormat将该字段视为毫秒，因此像782000这样的值会将这么多毫秒添加到总日期中。您必须处理您的字符串以使其与SimpleDateFormat的模式兼容。 -
基于很多样本数据点，6个字符代表微秒；但是，Windows 仅以 100 微秒的增量记录时间，因此这 6 个字符中只有前 4 个字符中有数据。我忽略了第 4 个字符，只想将前 3 位数字解析为毫秒。感谢有关预处理字符串的更详细的响应（例如，将 -420 分钟更改为正确的 -0700 时区）；如果您将其发布为答案，我会接受。