java - 我如何从 UUID 类型 1 中获取日期/时间

Question

我已经包含了以下 UUID 库

compile group: 'com.fasterxml.uuid', name: 'java-uuid-generator', version: '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())

然而，当我尝试查看日期时，它与应该的日期完全不同，例如，我得到 uid fef57eca-7c8b-11e8-bedd-992c2ac3197a was Sun Feb 06 07:55:54 GMT 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 和日期 Thu Aug 14 11:11:40 BST 4359073

Answer 1

我在网上做了更多搜索。

我构建了以下可以根据需要扩展的“简单实用程序”类:

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 timestamp() 方法处理为适用于正常 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

这对于脚本运行的时间来说看起来是正确的。