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.