TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Dates From:"Less is more." <yvonne -at- VENUS -dot- SMARTSTAR -dot- COM> Date:Mon, 12 Dec 1994 10:15:01 -0800
For applications the use the popular database systems, dates are covered for
the next few centuries. (I think most problems will occur with mainframe
applications.) FYI, these are the date ranges for some popular databases.
Informix January 1, 1 A.D. to December 31, 9999
Ingres January 1, 1582 to December 31, 2382
Oracle January 1, 4712 B.C. to December 31, 4712
RDB November 17, 1858 to December 31, 9999
Sybase January 1, 1753 to December 31, 9999
Internally, these databases store number of days or seconds or some unit of
time before or after a reference date. This means that the date is independent
of the display format you want to use. So, most systems provide ways to
display dates as MM/DD/YY, DD/MM/YY, DD MMM YYYY, YYYY-MM-DD, or whatever
your users need.
Also, many systems use an 8-byte variable instead of a long integer to store
values when both date and time information is needed in the same variable.
This gives enough space to store a date to the hundredth of a second for
a reasonable number of millennia.
