[Cosmo-dev] eim timestamp format

[Phillip J. Eby]

At 05:16 PM 1/3/2007 -0800, Brian Moseley wrote:
>On 1/3/07, Brian Moseley <bcm at osafoundation.org> wrote:
>
>> > I don't see any problem with it, although it seems to me that there's no
>> > reason to have a primitive type for it in that case; we might as well just
>> > use a "Decimal" subtype with an appropriate number of digits, and no
>> > decimal places.
>
>er .. what is the appropriate number of digits? :)

Python says 20 should suffice:

 >>> len(str(2**64))
20

:)


>can we not rely on 64 bit integers being available?

Python has 32-bit, variable-precision, and Decimal types.  Currently EIM 
has a 32-bit int type and a Decimal type, but no 64-bit or variable 
precision.  I'm not sure I see why we need another primitive type for this, 
since the idea is to keep primitive types simple and 
database-friendly.  Most SQL databases have some kind of decimal type, but 
not all of 'em have 64-bit ints, do they?

My most recent experience with 64-bit ints on e.g., Microsoft SQL Server is 
that its own ODBC drivers and client software doesn't handle them 
correctly!  (My wife is changing point-of-sale systems at her store right 
now and I've been tasked with data conversion, but that's another story.)

Anyway, my objection here is only a stylistic one, to avoid unnecessarily 
creating lots of static primitive types (e.g. 32 bits, 64 bits, 128 bits) 
when we already have the notion of decimal fields that can be parameterized 
to whatever number of digits.

But, if it's too difficult to convert a 20-digit decimal integer to a 
64-bit representation in Java and it'll hold up the project, then of course 
let's do it.