You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This might be a non-issue, but I realized that timestamps in vector clocks are defined as of year 0 instead of year 1970, leading to a 5-byte large integer encoding instead of the usual 4-byte encoding. Is that worth the potential performance hit?
The text was updated successfully, but these errors were encountered:
Basho-JIRA
changed the title
Gregorian vs. Unix timestamps
Gregorian vs. Unix timestamps [JIRA: RIAK-2346]
Jan 8, 2016
The reasons are mostly historical around the calendar module. There's no real need for anything beyond the time the vclock is first created in a cluster.
It's something we'd like to get around to re-engineering, but for Riak we need to worry about compatibility and changing to a more recent epoch will make them smaller and confusing.
This might be a non-issue, but I realized that timestamps in vector clocks are defined as of year 0 instead of year 1970, leading to a 5-byte large integer encoding instead of the usual 4-byte encoding. Is that worth the potential performance hit?
The text was updated successfully, but these errors were encountered: