日期格式标准
Contents
日期格式标准
如时间为: 2020-01-12T15:17:21 国际标准化组织的国际标准ISO 8601是日期和时间的表示方法，全称为《数据存储和交换形式·信息交换·日期和时间的表示方法》 原文如下：
日期和时间的组合表示法编辑 合并表示时，要在时间前面加一大写字母T，如要表示北京时间2004年5月3日下午5点30分8秒，可以写成2004-05-03T17:30:08+08:00或20040503T173008+08。
所以这个T date和time合并表示时，中间加个T。 iso 8806的百度地址是： https://baike.baidu.com/item/ISO%208601/3910715?fr=aladdin ———————————————— 版权声明：本文为CSDN博主「chushiyunen」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/enthan809882/article/details/103946177
https://www.cnblogs.com/tzyy/p/5099207.html
ISO日期格式标准,浏览器到服务器到MySQL中的时区
章节目录
时区简单理解
ISO_8601 日期格式标准
HTML5 input 标签datetime属性
MySQL时区
时区简单理解
https://zh.wikipedia.org/wiki/%E6%97%B6%E5%8C%BA
上面的链接是时区的wiki说明,下面说说我记住的部分:
GMT时区是格林威治标准时间,我把它理解为 “真实时间”
UTC时区是根据GMT得来的"世界标准时间”,它的时间和GMT是相同的
CST可以指下列的时区:
澳洲中部时间,Central Standard Time (Australia)
中部标准时区 (北美洲) ,Central Standard Time (North America)
北京时间,China Standard Time
古巴标准时间,Cuba Standard Time,参见北美东部时区
其中我们所在的时区背景时间 CST=UTC+8小时,也就是说,真实时间是0点的时候,背景时间是8点
ISO_8601日期格式标准
https://zh.wikipedia.org/wiki/ISO_8601
上面是日期格式标准的wiki
当前的UTC时间是2016-01-07T01:58Z, 其中Z是4位数字格式的时间偏移量, 不写的时候默认不偏移。
其中,字母T代表使用UTC时间,字母Z代表时间偏移量,实际写法中字母Z应该被偏移量替换,例如 “2017-1-7T10:21+0800"或者"2017-1-7T10:21-0800”,字母Z被+0800和-0800替换了。
在浏览器中直接new一个date对象,因为我们处于UTC+0800的时区,所以控制台给我们打印出来的时间是GMT+0800的时间
2016-01-07T00:00 代表UTC时区1月7日0时0分 (在控制台中显示UTC+0800时区为8时0分)
2016-01-07T00:00 0800 代表UTC+0800时区1月7日0时0分,2016-01-07T00:00 -0800 代表UTC-0800时区1月7日0时0分,在控制台中显示分别如下
通过日期字符串new一个Date对象,输入的时间字符串是2016-1-7 10:21,没有带ISO标准的"T"字母,因此浏览器认为我们想输入的是当地时间
HTML5 input标签datetime属性
下面问题来了,我要在页面上输入一个时间,存入数据库,上面说了那么多时区,那么用户在页面上输入的时间应该是哪个时区的呢,传到server,存入db的应该又是哪个时区的呢？
经测试
chrome上是不支持的
chrome支持
Google了一下据说是因为datetime输入框输入的是本地时区,考虑到时区的问题chrome没有支持此输入类型,会降级为text类型
datetime-local输入类型chrome是支持的,获取的value格式是:
“2016-1-7T10:21”
如上面所述,这个时间是标准UTC时间,这种时间从前端到后台到存入db,都是不会发生错误的。
但是对用户来说,他填写表单的时候想的时间肯定是他所在位置的本地时间,比如我输入"2016-1-7 10:21”,我真实想输入的时间是"2016-1-7T10:21+0800”,而不是"2016-1-7T10:21”。
为了支持这种情况,我需要把"2016-1-7T10:21"转换为用户真实想要的当地时间"2016-1-7 10:21”,于是"2016-1-7 10:21”.replace(“T”,” “),它实际代表的真实时间(UTC时间)是"2016-1-7T10:21+0800”
这样在前端是没问题了,但是传到后端之后,这样的非ISO标准时间是没有携带时区信息的,服务器收到之后会将这个时间安装服务器所在时区来处理,处理之后所代表的真实时间就和用户输入的真实时间不同了。所以我们在前端得把时间转换为ISO标准时间格式再传给服务器,这样服务器就能明白用户输入的真正的时间了,另一种方法,也可以把时间用毫秒数表示,传到后端,不过这种方式可读性不太好。
复制代码
// 1.将字面时间转化为本地时间 2.将本地时间转换为真实GMT时间传入后台
function getRealGMT(datetime){
datetime=datetime.replace(“T”,” “);
var temp=new Date(datetime);
var realGMT=temp.getTime()+temp.getTimezoneOffset()*60000;
return new Date(realGMT).format(“yyyy-MM-ddThh:mm”);
}
复制代码
转换效果如下:
MySQL时区
MySQL可通过 show variables like ‘%time_zone%'；命令来查看数据库设置的时区。我们的CST时区代表的是中国区的时区,即UTC+0800
所以服务器把从前端收到的ISO日期 “2016-1-7T02:21"收到之后,写入MySQL的datetime字段,MySQL的datetime字段会根据它的CST时区把日期转换过来,于是显示的日期就是"2016-1-7 10:21”,代表的真实时间是"2016-1-7T10:21+0800”
ISO 日期格式标准, 周数 ISO8601
时区简单理解
https://zh.wikipedia.org/wiki/%E6%97%B6%E5%8C%BA
上面的链接是时区的wiki说明，下面说说我记住的部分:
GMT时区是格林威治标准时间，我把它理解为 “真实时间”
UTC时区是根据GMT得来的"世界标准时间”，它的时间和GMT是相同的
CST可以指下列的时区:
澳洲中部时间，Central Standard Time (Australia)中部标准时区 (北美洲) ，Central Standard Time (North America)北京时间，China Standard Time古巴标准时间，Cuba Standard Time，参见北美东部时区
其中我们所在的时区背景时间 CST=UTC+8小时，也就是说，真实时间是0点的时候，背景时间是8点
ISO_8601 日期格式标准
https://zh.wikipedia.org/wiki/ISO_8601
上面是日期格式标准的wiki
当前的UTC时间是2016-01-07T01:58Z，其中Z是4位数字格式的时间偏移量，不写的时候默认不偏移。
其中，字母T代表使用UTC时间，字母Z代表时间偏移量，实际写法中字母Z应该被偏移量替换，例如 “2017-1-7T10:21+0800"或者"2017-1-7T10:21-0800”，字母Z被+0800和-0800替换了。
在浏览器中直接new一个date对象，因为我们处于UTC+0800的时区，所以控制台给我们打印出来的时间是GMT+0800的时间
2016-01-07T00:00 代表UTC时区1月7日0时0分 (在控制台中显示UTC+0800时区为8时0分)
2016-01-07T00:00 0800 代表UTC+0800时区1月7日0时0分，2016-01-07T00:00 -0800 代表UTC-0800时区1月7日0时0分，在控制台中显示分别如下
通过日期字符串new一个Date对象，输入的时间字符串是2016-1-7 10:21，没有带ISO标准的"T"字母，因此浏览器认为我们想输入的是当地时间
https://zoucz.com/blog/2016/01/29/date-iso/
周数
ISO8601 中周的介绍及 Joda-Time 的使用
沈颖 2017.05.26 09:30:05 字数 790 阅读 1,174 不知道你是否忍受够了JDK 中对周这种日期的处理，比如 2017-1-1.这天不知道你是该记为 2017年的第0周，还是第一周。而且周日到底是每周的第1天，或者是第0天，或者是周一才是每周的第1天，周日是第7天。总之，各个国家和地区都有不同的统计方式，而且中国古代历法根本就没有周的概念，也就是说周对于我们来说是个舶来品。统计方式每个人和组织都有不同的见解，虽然有国家标准，鲜有人去统一执行。
还好，国际化标准组织的国际标准ISO 8601 对日期和时间的表示方法做出了明确规定，周数也计算方式也做了详细的说明，包括中国在内的国家标准 GB/T 7408-2005 都是依据该标准扩展而来。
根据ISO 8601 的规则。
每年有52周或者53周
周一至周日为一个完整周。
每周的周一是该周的第1天。周日是该周的第7天
每年的第一周 为 每年的第一个周四所在的周。比如 2017年1月5日为当年的第一个周四，那么 2017-01-02 至 2017-01-08 为2017年第一周
每年的最后一周为当年最后一个周四所在的周。比如2016年12月29日为当年的最后一个周四，那么2016-12-26 至2017-01-01 为2016年的最后一周。
周年，当前周所在的年份为周年。比如 2017年1月1日的周年为2016年。2016年1月1日，2016年1月2日，2016年1月3日的周年均为2015年。
既然有了这么好的一个国际标准，大部分编程语言自然会对其支持。我们就按照这个标准执行，在数据的计算上就不应该有问题了，可是偏偏JDK1.7 及其之前的版本居然都不支持ISO 8601 标准。还好民间的力量比较大。有众多API包都发布了对ISO 8601 的支持，其中joda-time最为流行。
Author -
LastMod 2018-07-25