Tim Peters wrote: > > [Jim Fulton] > > ZODB has a TimeStamp type that uses a 32-bit unsigned integer > > to store year, month,, day, hour, and minute in a way that makes it dirt > > simple to extract a component. > > You really think so? It's a mixed-radix scheme: > > v=((((y-1900)*12+mo-1)*31+d-1)*24+h)*60+m; > > so requires lots of expensive integer division and remainder operations to > pick apart again (the trend in CPUs is to make these relatively more > expensive, not less, and e.g. Itanium doesn't even have an integer division > instruction). Compared to storing date-times as offsets from an epoch, this is much simpler and cheaper. > If we had this to do over again, I'd strongly suggest assigning 12 bits to > the year, 4 to the month, 5 each to day and hour, and 6 to the minute. The > components would then be truly dirt simple and dirt cheap to extract, and we > wouldn't even have to bother switching between 0-based and 1-based for the > months and days (let 'em stay 1-based). They would still sort and compare > correctly in packed format. The only downside I can see is that not > pursuing every last drop of potential compression would shrink the dynamic > range from 8000+ years to 4000+ years, but we're likely to have much worse > problems in Zope by the year 5900 anyway <wink>. Sounds good to me. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (888) 344-4332 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4