openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-361) Incorrect GREG_OFFSET offset or inconsistent usage in UUIDGenerator
Date Mon, 10 Sep 2007 23:02:29 GMT

    [ https://issues.apache.org/jira/browse/OPENJPA-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526296
] 

Kevin Sutter commented on OPENJPA-361:
--------------------------------------

> I'm concerned about the backward-compat issue, but haven't done any analysis of it.

I don't think we have anything to worry about.  Looking at the incorrect value that was being
used for the Gregorian Offset, we were basically adding somewhere around 380 years to the
current time.  So, the possibility of someday matching up a new generated UUID (with the correct
Gregorian offset) with an old one is next to nil.  Especially when you bring the other aspects
of the UUID into play (IP, clock sequence, etc).

I'm going to go ahead with this commit.

Kevin

> Incorrect GREG_OFFSET offset or inconsistent usage in UUIDGenerator
> -------------------------------------------------------------------
>
>                 Key: OPENJPA-361
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-361
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: lib
>    Affects Versions: 1.0.0
>         Environment: All platforms
>            Reporter: Albert Lee
>            Assignee: Albert Lee
>            Priority: Trivial
>         Attachments: OPENJPA-361.patch
>
>
> In UUIDGenerator, GREG_OFFSET is defined as
>     // offset to move from 1/1/1970, which is 0-time for Java, to gregorian
>     // 0-time 10/15/1582, and multiplier to go from 100nsec to msec units
>     private static final long GREG_OFFSET = 0x01b21dd213814000L;
> This constant is used as:
>         // calculate time as current millis plus offset times 100 ns ticks
>         long currentTime = (_currentMillis + GREG_OFFSET) * MILLI_MULT;
> Based of the usage, GREG_OFFSET should be in msec unit and this value should be
>     (1970-1582) * 365.25 * 24 * 3600 * 1000 (ms) = 12,219,292,800,000 (ms) = 0xB1D 069B
5400 (ms)
> The defined constant value 0x1b21dd213814000L is the last value in 100ns unit not ms.

> This also offsets the currentTime calculation off by a factor of 10**4.
> To correct the discrepency, either:
> 1) GREG_OFFSET should assign the value of 0xB1D 069B 5400L instead of 0x1b2 1dd2 1381
4000L, or
> 2) long currentTime = (_currentMillis * MILLI_MULT ) + GREG_OFFSET ;
> Since UUID is an arbituary value, therefore I don't believe the current implementation
is "incorrect" but just inconsistent in its implementation description. 
> Please comment on if:
> 1) the suggested change will have any undesirable side-effect for UUID
> 2) there is any legacy/backward compatibility problem
> 3) this is worth to change at all.
> If there is no objection, I'll correct the "problem" early next week.
> Albert Lee.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message