{"issue":{"milestone":null,"user":{"id":508118,"login":"ctavan","url":"https://api.github.com/users/ctavan","avatar_url":"https://secure.gravatar.com/avatar/3bc5e1eb910b307b5b723f9fa25db108?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"3bc5e1eb910b307b5b723f9fa25db108"},"created_at":"2011-12-18T11:24:14Z","title":"Uniqueness of v1 UUIDs if msecs is set.","updated_at":"2011-12-18T15:22:23Z","labels":[],"state":"open","id":2592969,"html_url":"https://github.com/broofa/node-uuid/issues/24","closed_at":null,"pull_request":{"patch_url":null,"html_url":null,"diff_url":null},"body":"While implementing node-uuid with node-cassandra-client I came across this test written by the node-cassandra-client authors: https://github.com/ctavan/node-cassandra-client/blob/node-uuid/test/test_uuid.js#L13-29\r\n\r\nIt fails with node-uuid since setting `msecs` bypasses the internal clockseq-counter. What was the particular reason for you to put it that way? The only reason I can see is code readability.\r\n\r\nReading through the RFC again, IMO setting `msecs` and `nsecs` to a value in the future and then to a value lower than that future-value can just be interpreted as \"setting the clock backwards\". So unless the `clockseq` is explicitly specified I think node-uuid should take care of setting the clockseq according to the RFC (and not the calling application, which would be necessary at the moment).\r\n\r\nI admit that this will add complexity to the v1 logic, but still I think it would be more in the sense of the RFC... What are your thoughts?","number":24,"url":"https://api.github.com/repos/broofa/node-uuid/issues/24","comments":1,"assignee":null},"comment":{"user":{"id":164050,"login":"broofa","url":"https://api.github.com/users/broofa","avatar_url":"https://secure.gravatar.com/avatar/2edce239a83772318425ae41aee4f637?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"2edce239a83772318425ae41aee4f637"},"created_at":"2011-12-18T15:22:23Z","updated_at":"2011-12-18T15:22:23Z","id":3195193,"body":"@ctavan - I believe when you and @pnegri suggested supporting an `options` argument, it was for the purpose of doing unit tests (in Cassondra, no less).  I coded v1() this way because when doing unit tests, it's generally nice to have deterministic behavior so you can do things like `assert.equal(uuid.v1({msecs: 123}), '139404b0-1dd2-11b2-9876-6339347e988e')`.\r\n\r\nHowever if that's not the behavior we want it's certainly easy enough to change.","url":"https://api.github.com/repos/broofa/node-uuid/issues/comments/3195193"},"action":"created"}