From: Mark D. ⌛ <ma...@ma...> - 2009-09-03 21:23:13
|
Markus understood that. The issue is that we *don't need* the granularity of 64 bits. And given that we don't need it, then we would be increasing the size to no advantage. We would need to bump the version of the file and add a field with the granularity. As to whether we also change the file name, so that we know externally, I don't have a strong opinion. Mark On Thu, Sep 3, 2009 at 14:15, Jason J Spieth <sp...@us...> wrote: > > Hello Markus, > > Each transition is still a single "integer" however the representation is > different. > > In the current zoneinfo the transition list is an integer vector where each > element is a 32 bit integer. > > The main thrust of the proposal is that this transition list representation > would change. Instead of being a 32 bit integer in an intvector it would > be a signed packed 8 byte binary representation (64 bits). > > Quick example (the hex data may not be 100% correct but it is just to give > an example of the representation): > old zoneinfo: > > , /* Africa/Banjul */ :array { > :intvector { -2147483648, -1830380004, -1104533604, -189385200 } > :intvector { -3996, 0, -3600, 0, 0, 0 } > :bin { "00000102" } > } //Z#13 > > new zoneinfo64: > > , /* Africa/Banjul */ :array { > :bin {"8000000092E69E1CBE2A279CF4B63610"} > :intvector { -3996, 0, -3600, 0, 0, 0 } > :intvector { 0, 0, 1, 2 } > } //Z#13 > > where the bin vector would get parsed as signed 8 byte values: > 80000000, 92E69E1C, BE2A279C, F4B63610 > > ===== > > The idea of changing the granularity from seconds to minutes is not one I > think was proposed, and is an interesting idea that might be worth > additional discussion. > > However I think by changing to a 64 bit representation in zoneinfo itself > gives an even greater range than just changing granularity. > > Also with the generator, while adding the ability via command line arg or > some such to generate either output is desirable, if the output always has > the same name, that would be very confusing to the user as to which version > they have without looking at the data itself. > > If I have a zoneinfo.txt/res file, I have to look at the contents to know > if it using 32 bit data to use in ICU 4.2 and earlier or 64 bit data to use > in ICU4.4 and later. > > > > > *Markus Scherer <mar...@gm...>* > > 09/03/2009 03:21 PM > Please respond to > icu...@li... > > To > icu...@li... cc > Subject > Re: [icu-design] Proposal to support 64 bit time transitions in ICU > > > > > Hi Jason, > > It's not quite clear to me from your description what's different between > zoneinfo and zoneinfo64. Is the only difference that you use pairs of ints > per transition, rather than single ints? If you are making this kind of > change, then I think true 64-bit transition times (pairs of 32-bit ints) in > the data file are overkill. > > Instead, I propose that we continue to use single-int transitions, but > change the granularity. For example, rather than 64-bit seconds from 1970 we > could encode 32-bit minutes from 1970, which would extend the range of > transition times 60-fold with minor changes to code and data structure, and > without the significant data size increase that comes with doubling the > space per transition. I am pretty sure that all TZ database transitions are > multiples of minutes (maybe even multiples of 15 minutes). And I am pretty > sure we don't need a larger range than about 2000BC..6000AD that we get with > minutes from 1970. > > We should add a new item in zoneinfo.res for the granularity, and new code > could use that as a multiplier. > > I think we should keep the zoneinfo.res filename, and tell the generator > tool via a command-line parameter to output the old format (with limitations > in the range of transition times) vs. the new format (with the granularity > field and a larger range). > > Best regards, > markus > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. > http://p.sf.net/sfu/bobj-july_______________________________________________ > icu-design mailing list > icu...@li... > To Un/Subscribe: https://lists.sourceforge.net/lists/listinfo/icu-design > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > icu-design mailing list > icu...@li... > To Un/Subscribe: https://lists.sourceforge.net/lists/listinfo/icu-design > |