Is there a limit on integers? Limit on the number of digits and/or their value? I haven't been able to find anything in the manuals that gives an indication of what it might be.

I was in the middle of writting a quick little program that myself and fellow programers could use to quickly translate Arev 3.12 internal date and time integer numbers into something readable and visa versa (occasionaly we have to look at the raw data to get an idea of why a problem occured) . I ran a quick program to find the upper and lower limits (just for grins). I expected that at some point I would just get a null value back from the date conversion as you do with an incorrect date for the ICONV. My findings are that any numbers less than -2148202443 and greater than 2146764851 give me a date of "12 Jul 9610".

I realize that these numbers for dates are very unrealistic for everyday sort of stuff. What I would like to know is, are these numbers the limits of what an integer value can hold or just the limit of the OCONV date function?

Also is there any way to designate a year as AD or BC thru the date conversion? I assume that it would be a programming issue for the person needing that kind of information as opposed to a system issue.

Thanks,

Michael Slack

E-mail: [email protected]

As a general observation relating to dates…

(1) AREV does handle integer dates, and is constrained

by size in some routines, including assembly language

routines where the parameters are typed (long int, short

int, double, string etc…) There are reasonable limits,

and few have complained about limits in the past.

(2) The Julian Calendar switched to Gregorian (in

1600's?) and 9 days were lost, so BC is less

meaningful, or would require accommodation.

(3) You could write your own input/output conversion

routine to do the special date cases.

(4) You could store a letter ahead of the numeric string

and add it ahead of storage and strip it off ahead of

display, thereby overcoming your scientific notation

limitation, keeping a sortable field internally and

using "superintegers". Remember the negative sign.

(5) There are examples of date iconv functions on my

web page at http://www.ozemail.com.au/~stsm/

source code is included (these are good only to 2056AD

but can be readily modified to handle bigger dates

such as 32 bit dates)

(6) You could always store dates as strings eg.

15 Octember 34568365209 BC - first amino acid crawls

from primeval slime and develops Group Format Error.

You could handle date calcs anbd sorting via your own

custom routine, or symbolics on part of the date field.

eg. List file by date becomes List file by year by

month by day.

Hope this helps,

Steve

Michael,

My findings are that any numbers less than -2148202443 and greater than 2146764851 give me a date of "12 Jul 9610". I realize that these numbers for dates are very unrealistic for everyday sort of stuff. What I would like to know is, are these numbers the limits of what an integer value can hold or just the limit of the OCONV date function?

These are the limits of signed 32-bit integers. The positive limit is 2^31-1 (or 2147483647) and the negative limit is -2147483648. Using 2's complement with 32 bits to express positive or negative numbers, no numbers outside that range can be described.

Cameron Purdy

Revelation Software

As suggested by your home page, it looks like you might be cataloging information from a looooong time ago. My suggestion is similar to Mr. Smith's: create your own dating methodology.

Rev's dating sequence starts at Jan 1, 1968 and counts forwards and backwards from there. However, this won't let you go back very far.

My thoughts would be to store the year in its own field in scientific notation. This will get you back quite a way. Another field could be used for a month, quarter, or season, whatever is required. I don't recall how many digits are kept or how accurate you need to be. Sorts will need to be changed to reflect your algorithm.

Just a thought.

Charles Schmdling

DATASCAN Systems, Inc.

[email protected]

View this thread on the forum...