我已经包括以下UUID库编译组:“com.fasterxml.uuid”,名称:“Java的UUID发电机”,版本:“3.1.5”在我的构建。
我有一些像这样的代码
NoArgGenerator timeBasedGenerator = Generators.timeBasedGenerator()
UUID tuid = timeBasedGenerator.generate()
Timestamp timestamp = new Timestamp ((tuid.timestamp()/1000) as Long)
Date dateTime = new Date (timestamp.getTime())
然而,当itry,并期待在日像它应该是什么,所以例如我得到“UID fef57eca-7c8b-11E8-BEDD-992c2ac3197a是太阳2月6七点55分54秒格林尼治标准时间6327”当今天是其分毫30/06 / 2018
有谁知道如何正确地提取使用fasterxml.uuid库基于时间的UUID真正的日期和时间?
但难倒
PS试过这种替代
UUID tuid = timeBasedGenerator.generate()
Long t = tuid.timestamp()
Timestamp timestamp = new Timestamp (t)
Date dateTime = new Date (timestamp.getTime())
这给周四的UID ff79d7d9-7cb5-11e8-976c-6ba57a5e9636和日期8月14日11时11分四十秒BST 4359073
我做多一些在网络上搜索。
我建立了一个可扩展的需要以下“简单实用”类:
import com.fasterxml.uuid.Generators
import com.fasterxml.uuid.NoArgGenerator
class UuidUtil {
static final NoArgGenerator timeBasedGenerator = Generators.timeBasedGenerator()
/**
* From UUID javadocs the resulting timestamp is measured in 100-nanosecond units since midnight, October 15, 1582 UTC
* timestamp() from UUID is measured in 100-nanosecond units since midnight, October 15, 1582 UTC
*
* The Java timestamp in milliseconds since 1970-01-01 as baseline
*
* @return
*/
static long getStartOfUuidRelativeToUnixEpochInMilliseconds () {
Calendar c = Calendar.getInstance(TimeZone.getTimeZone("GMT-0"))
c.set(Calendar.YEAR, 1582)
c.set(Calendar.MONTH, Calendar.OCTOBER)
c.set(Calendar.DAY_OF_MONTH, 15)
c.set(Calendar.HOUR_OF_DAY, 0)
c.set(Calendar.MINUTE, 0)
c.set(Calendar.SECOND, 0)
c.set(Calendar.MILLISECOND, 0)
return c.getTimeInMillis()
}
//https://www.wolframalpha.com/input/?i=convert+1582-10-15+UTC+to+unix+time
final static long START_OF_UUID_RELATIVE_TO_UNIX_EPOCH_SECONDS = -12219292800L
final static long START_OF_UUID_RELATIVE_TO_UNIX_EPOCH_MILLIS = -12219292800L * 1000L
/**
* timestamp() from UUID is measured in 100-nanosecond units since midnight, October 15, 1582 UTC,
* so we must convert for 100ns units to millisecond procession
* @param tuid
* @return
*/
static long getMillisecondsFromUuid (UUID tuid) {
assert tuid.version() == 1 //ensure its a time based UUID
// timestamp returns in 10^-7 (100 nano second chunks),
// java Date constructor assumes 10^-3 (millisecond precision)
// so we have to divide by 10^4 (10,000) to get millisecond precision
long milliseconds_since_UUID_baseline = tuid.timestamp() /10000L
}
static getDateFromUuid (UUID tuid) {
// Allocates a Date object and initializes it to represent the specified number of milliseconds since the
// standard java (unix) base time known as "the epoch", namely January 1, 1970, 00:00:00 GMT
// have to add relative offset from UUID start date of unix epoch to get start date in unix time milliseconds
new Date (getMillisecondsFromUuid (tuid) + START_OF_UUID_RELATIVE_TO_UNIX_EPOCH_MILLIS )
}
static UUID getTimeBasedUuid () {
UUID tuid = timeBasedGenerator.generate()
}
}
我已经添加了解释性注释,这样就可以跟着你不得不做处理UUID时间戳()方法为,对于普通的Java日期和时间处理工作的格式是什么。
为什么Java的UUID类不能提供人们所预料的,使基于时间的UUID与基于正常的Unix纪元普通的Java日期/时间格式互操作的方法是一个谜给我。
我使用上述静态方法跑一个小的测试脚本:
println "get start of epoch in milliseconds " + UuidUtil.getStartOfUuidRelativeToUnixEpochInMilliseconds()
assert UuidUtil.START_OF_UUID_RELATIVE_TO_UNIX_EPOCH_MILLIS == UuidUtil.startOfUuidRelativeToUnixEpochInMilliseconds
UUID tuid = UuidUtil.timeBasedUuid
println "uid : $tuid"
Date date = UuidUtil.getDateFromUuid(tuid)
println "extracted date from uid is " + UuidUtil.getDateFromUuid(tuid)
而得到这个
get start of epoch in milliseconds -12219292800000
uid : 43acb588-7d39-11e8-b37b-59f77bf2d333
extracted date from uid is Sun Jul 01 15:15:53 BST 2018
这看起来正确的时间运行脚本。