SimpleDateFormat在jdk1.6与jdk1.7之间的差别

原创 2015年11月18日 17:33:52

一:SimpleDateFormat简介

SimpleDateFormat is a concrete class for formatting and parsing dates in a locale-sensitive manner. It allows for formatting (date -> text), parsing (text -> date), and normalization.

SimpleDateFormat allows you to start by choosing any user-defined patterns for date-time formatting. However, you are encouraged to create a date-time formatter with either getTimeInstance, getDateInstance, or getDateTimeInstance in DateFormat. Each of these class methods can return a date/time formatter initialized with a default format pattern. You may modify the format pattern using the applyPattern methods as desired. For more information on using these methods, see DateFormat.
Date and Time Patterns

Date and time formats are specified by date and time pattern strings. Within date and time pattern strings, unquoted letters from ‘A’ to ‘Z’ and from ‘a’ to ‘z’ are interpreted as pattern letters representing the components of a date or time string. Text can be quoted using single quotes (‘) to avoid interpretation. “”” represents a single quote. All other characters are not interpreted; they’re simply copied into the output string during formatting or matched against the input string during parsing.

The following pattern letters are defined (all other characters from ‘A’ to ‘Z’ and from ‘a’ to ‘z’ are reserved):

Letter  Date or Time Component  Presentation    Examples
G   Era designator  Text    AD
y   Year    Year    1996; 96
M   Month in year   Month   July; Jul; 07
w   Week in year    Number  27
W   Week in month   Number  2
D   Day in year     Number  189
d   Day in month    Number  10
F   Day of week in month    Number  2
E   Day in week     Text    Tuesday; Tue
a   Am/pm marker    Text    PM
H   Hour in day (0-23)  Number  0
k   Hour in day (1-24)  Number  24
K   Hour in am/pm (0-11)    Number  0
h   Hour in am/pm (1-12)    Number  12
m   Minute in hour  Number  30
s   Second in minute    Number  55
S   Millisecond     Number  978
z   Time zone   General time zone   Pacific Standard Time; PST; GMT-08:00
Z   Time zone   RFC 822 time zone   -0800

Pattern letters are usually repeated, as their number determines the exact presentation:

Text: For formatting, if the number of pattern letters is 4 or more, the full form is used; otherwise a short or abbreviated form is used if available. For parsing, both forms are accepted, independent of the number of pattern letters.
Number: For formatting, the number of pattern letters is the minimum number of digits, and shorter numbers are zero-padded to this amount. For parsing, the number of pattern letters is ignored unless it's needed to separate two adjacent fields.
Year: If the formatter's Calendar is the Gregorian calendar, the following rules are applied.
    For formatting, if the number of pattern letters is 2, the year is truncated to 2 digits; otherwise it is interpreted as a number.
    For parsing, if the number of pattern letters is more than 2, the year is interpreted literally, regardless of the number of digits. So using the pattern "MM/dd/yyyy", "01/11/12" parses to Jan 11, 12 A.D.
    For parsing with the abbreviated year pattern ("y" or "yy"), SimpleDateFormat must interpret the abbreviated year relative to some century. It does this by adjusting dates to be within 80 years before and 20 years after the time the SimpleDateFormat instance is created. For example, using a pattern of "MM/dd/yy" and a SimpleDateFormat instance created on Jan 1, 1997, the string "01/11/12" would be interpreted as Jan 11, 2012 while the string "05/04/64" would be interpreted as May 4, 1964. During parsing, only strings consisting of exactly two digits, as defined by java.lang.Character.isDigit(char), will be parsed into the default century. Any other numeric string, such as a one digit string, a three or more digit string, or a two digit string that isn't all digits (for example, "-1"), is interpreted literally. So "01/02/3" or "01/02/003" are parsed, using the same pattern, as Jan 2, 3 AD. Likewise, "01/02/-3" is parsed as Jan 2, 4 BC. 
Otherwise, calendar system specific forms are applied. For both formatting and parsing, if the number of pattern letters is 4 or more, a calendar specific java.util.Calendar.LONG is used. Otherwise, a calendar specific short or abbreviated form is used.
Month: If the number of pattern letters is 3 or more, the month is interpreted as text; otherwise, it is interpreted as a number.
General time zone: Time zones are interpreted as text if they have names. For time zones representing a GMT offset value, the following syntax is used:

     GMTOffsetTimeZone:
             GMT Sign Hours : Minutes
     Sign: one of
             + -
     Hours:
             Digit
             Digit Digit
     Minutes:
             Digit Digit
     Digit: one of
             0 1 2 3 4 5 6 7 8 9

Hours must be between 0 and 23, and Minutes must be between 00 and 59. The format is locale independent and digits must be taken from the Basic Latin block of the Unicode standard.

For parsing, RFC 822 time zones are also accepted.
RFC 822 time zone: For formatting, the RFC 822 4-digit time zone format is used:

     RFC822TimeZone:
             Sign TwoDigitHours Minutes
     TwoDigitHours:
             Digit Digit

TwoDigitHours must be between 00 and 23. Other definitions are as for general time zones.

For parsing, general time zones are also accepted. 

SimpleDateFormat also supports localized date and time pattern strings. In these strings, the pattern letters described above may be replaced with other, locale dependent, pattern letters. SimpleDateFormat does not deal with the localization of text other than the pattern letters; that’s up to the client of the class.

Examples
The following examples show how date and time patterns are interpreted in the U.S. locale. The given date and time are 2001-07-04 12:08:56 local time in the U.S. Pacific Time time zone.

Date and Time Pattern   Result
"yyyy.MM.dd G 'at' HH:mm:ss z"  2001.07.04 AD at 12:08:56 PDT
"EEE, MMM d, ''yy"  Wed, Jul 4, '01
"h:mm a"    12:08 PM
"hh 'o''clock' a, zzzz"     12 o'clock PM, Pacific Daylight Time
"K:mm a, z"     0:08 PM, PDT
"yyyyy.MMMMM.dd GGG hh:mm aaa"  02001.July.04 AD 12:08 PM
"EEE, d MMM yyyy HH:mm:ss Z"    Wed, 4 Jul 2001 12:08:56 -0700
"yyMMddHHmmssZ"     010704120856-0700
"yyyy-MM-dd'T'HH:mm:ss.SSSZ"    2001-07-04T12:08:56.235-0700

二:问题描述

最近在联调一个Socket连接的时候出了一个问题,服务端提供了一个工具类来组装报文,我在本地JDK1.7环境跑程序的时候没有问题,但是本地调试好后发布到linux上的JDK1.6之后就发现一直访问服务端超时。这让我百思不得其解,各种可能出现问题的场景都试了个遍,比如:是不是和jboss服务器有关系、是不是部署在项目的问题(单独写一个java直接调用是可以的)。最中把本地正常生成的报文和服务器上生成的比对才发现了问题,发现本地的报文段中时间的部分是这样的

20151117111242

但是服务器上对应这段的时间部分是这样的

151117111242

这时候才恍然大悟,应该是提供的工具类中的格式化时间的地方有问题,果不其然工具类中的格式化代码如下

SimpleDateFormat df = new SimpleDateFormat("yyyMMddHHmmss");//设置日期格式

乍一看没什么问题,细细一看发现构造方法的pattern字符串中竟然少了一个y
就是这少了一个y费了2*2人/天时间,这是多么惨痛的代价啊。所以我看了看SimpleDateFormat的源码发现了JDK1.7与JDK1.6对于这种非正常格式化的处理的区别

  1. JDK1.7的subFormat方法中相关的代码片如下
         case PATTERN_YEAR:      // 'y'
            if (calendar instanceof GregorianCalendar) {
                if (count != 2)
                    zeroPaddingNumber(value, count, maxIntCount, buffer);
                else // count == 2
                    zeroPaddingNumber(value, 2, 2, buffer); // clip 1996 to 96
            } else {
                if (current == null) {
                    zeroPaddingNumber(value, style == Calendar.LONG ? 1 : count,
                                      maxIntCount, buffer);
                }
            }
            break;
  1. JDK1.6的subFormat方法中相关的代码片如下
            case 1: // 'y' - YEAR
            if (calendar instanceof GregorianCalendar) {
                if (count >= 4)
                    zeroPaddingNumber(value, count, maxIntCount, buffer);
                else // count < 4
                    zeroPaddingNumber(value, 2, 2, buffer); // clip 1996 to 96
            } else {
                if (current == null) {
                    zeroPaddingNumber(value, style == Calendar.LONG ? 1 : count,
                    maxIntCount, buffer);
                }
            }
            break;

看到这里就了解了为什么本地是正常的而服务器上是不正常的了,因为生成报文时有两处这样的时间戳,导致服务器上最后生成的报文比要求的少了四个字符,所以服务端没有收取消息没有正常的结束,一直在读取,读到服务器socket连接超时,每次都是这样。

三:以上问题的总结

作为码农的我们写代码的时候还是要多加细心,不然可能一个小小的疏忽可能浪费数倍的人力和时间去排查和解决它。以上虽然不是自己的失误,但是还是有自己太相信别人的成分在里面而没有仔细看工具类,所以记录在此为自己时刻提一个醒。

版权声明:本文为博主原创文章,未经博主允许不得转载。

相关文章推荐

SimpleDateFormat在jdk不同版本的差异

在y-m-d这种格式的时候,JDK 1.6会只取年的后两位,而JDK 1.7会显示完整的四位。 String time = "2015-1-1"; SimpleDateFormat format =...

JDK1.7的新语法,你经常使用吗?

JDK1.7的新语法,你经常使用吗? 用惯了JDK6的语法,对后来 7的更新也忽略了,今天总结一下,作为开发人员 还是要与时俱进的.要不时间久了就淘汰喽 1:对整型支持改进。 int i = 0...

JDK7新特性详细说明及代码示例

在2011年7月28日,Oracle发布了JDK7的正式版。最近我从网上搜集了一些资料,把文字说明和代码示例结合起来,方便我们的学习。 下面我们来看看JDK7比6多了哪些新特性 1、访问文件系统 ...

JDK1.5,1.6,1.7,1.8新增特性

JDK1.5,1.6,1.7,1.8新增特性 JDK1.5新特性 1.静态导入(import static) import语句可以导入一个类或是某个包中的所有类。 import static ...

JDK 1.7的新变化 (java)

点击进入下载页面 点击下载jdk1.7  1.优化了对集合的支持,创建List / Set / Map 时写法更简单了。 ListString> list = ["item"];St...

给定A, B两个整数,不使用除法和取模运算,求A/B的商和余数

给定A, B两个整数,不使用除法和取模运算,求A/B的商和余数。 1.   最基本的算法是,从小到大遍历: for (i = 2 to A -1)          if (i * B > A)...

利用K-means聚类算法根据经纬度坐标对中国省市进行聚类

K-means聚类算法是一种非层次聚类算法,在最小误差的基础上将数据划分了特定的类,类间利用距离作为相似度指标,两个向量之间的距离越小,其相似度就越高。程序读取全国省市经纬度坐标,然后根据经纬度坐标进...

Radon变换理论介绍与matlab实现--经验交流

本人最近在研究Radon变换,在查阅了各种资料之后在此写下个人的理解,希望与各位牛牛进行交流共同进步,也使得理解更加深刻些。 Radon变换的本质是将原来的函数做了一个空间转换,即,将原来的XY平...

CT图像重建技术

由于csdn贴图不方便,并且不能上传附件,我把原文上传到了资源空间CT图像重建技术 1.引言 计算机层析成像(Computed Tomography,CT)是通过对物体进行不同角度的射线投影测量而...

Matlab绘图-很详细,很全面

Matlab绘图强大的绘图功能是Matlab的特点之一,Matlab提供了一系列的绘图函数,用户不需要过多的考虑绘图的细节,只需要给出一些基本参数就能得到所需图形,这类函数称为高层绘图函数。此外,Ma...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:SimpleDateFormat在jdk1.6与jdk1.7之间的差别
举报原因:
原因补充:

(最多只允许输入30个字)