问题原因
：开发写了两个方法，入参都为Date时间。一个计算入参对应周的开始时间，另一个计算对应周的结束时间，但是计算对应周开始时间中存在问题。
创建任务时，选择时间只是年月日，所以最后传递过去的13位时间戳，后三位的毫秒数肯定是0。
进入创建任务界面，查询时，由于传递的是当前时间，对应的13位时间戳的后三位肯定不为0。
导致的问题
：由于两种场景计算出来的时间不一致，而对应查询数据的SQL就会不一致（mysql中between是前闭后闭区间[]）。
创建任务（正常情况）: market_time BETWEEN ‘2021-06-21 00:00:00’ AND ‘2021-06-27 23:59:59.999’
查询信息（异常情况）：market_time BETWEEN ‘2021-06-21 00:00:00.387’ AND ‘2021-06-27 23:59:59.999’
而如果存在运
long time1 = System.currentTimeMillis();
long time2 = Calendar.getInstance().getTimeInMillis();
long time3 = new Date().getTime();
10位的时间
戳
的三种方式
long time1 = System.currentTimeMillis() / 1000;
long time2 = Calendar.getInstance().getTim
昨晚在写代码的时候。要用到时间
戳
，当时获取出来后发现这时间
戳
好长，跟之前印象中的长度不一样，去网上查了一下，才知道，这时间
戳
是有
13
位和10位之分，其实就是
毫秒
和秒之分，
毫秒
单位的时间
戳
就是
13
位，秒单位的时间
戳
就是10位。
我用的是
java
开发，直接通过获取系统时间的时间
戳
就是
13
位的
13
位时间
戳
：
Long time = System.currentTimeMillis();
通过 Date 获取时间
戳
：
Date date = new Date();
Long time = date.get
一、
毫秒
、微秒名词解释：
毫秒
：millisecond -- 千分之一秒 微秒：microsecond -- 一百万分之一秒 1 秒 = 1000
毫秒
；1
毫秒
= 1000 微秒
10
位时间
戳
的单位是秒
13
位时间
戳
的单位是
毫秒
下面首先给出结论，
13
位时间
戳
存储要么存为bigint，要么存为varchar(...
问题1：为什么会生成
13
位的时间
戳
，
13
位的时间
戳
和10时间
戳
分别是怎么来的
经过百度得知，原来
java
的date默认精度是
毫秒
，也就是说生成的时间
戳
就是
13
位的，而像c++或者php生成的时间
戳
默认就是10位的，因为其精度是秒。
问题2：
13
位时间
戳
如何转换成10
位时间
戳
本来以为
java
中有设置可以修改其时间精度，后来在百度上没有找到，就只能采用其它方法来转化，这里提供两种方式来转换。
第一种...
固定日期转换成时间
戳
select unix_timestamp('2016-08-16','yyyy-MM-dd') --1471276800
select unix_timestamp('20160816','yyyyMMdd') --1471276800
select unix_timestamp('2016-08-16T10:02:41Z',
"
yyyy-MM-dd'T'HH:mm:ss'Z'
"
) --147
13
12961
16/Mar/2017:12:25:01 +0800 转成正常格式（yyy
def timeStamp(timeNum):
timeStamp = float(timeNum/1000)
timeArray = time.localtime(timeStamp)
otherStyleTime = time.strftime("%Y-%...
