Developing Time-Oriented Database Applications in SQL
An enjoyable plunge into the how-to of time and data, with real-world situations and code.
TABLE OF CONTENTS Developing Time-Oriented Database Applications in SQL
Section 3.7: SUBTLETIES*
3.7 SUBTLETIES*
It is critical that the limitations and subtle ramifications of the representation of instants provided by the DBMS be understood. As we'll see, the meaning of a temporal value is somewhat arbitrary, with the application providing some of the semantics.
3.7.1 Datetimes
While an instant is, well, instantaneous, SQL and all DBMSs assume a discrete time line of various granularities, such as second, day, and year, and indicate only the particular granule in which the instant is located. The event of an individual well sample extraction occurred at a specific instant, but we may care to record only the
The prevailing system before the use of B.C. A.D., at least in the Western world, was A.U.C. ( ab urbecondita, literally, "from the foundation of the city," which, being in Latin, of course meant Rome). Dionysius (see page 27) pegged 1 A.D. at 754 A.U.C. There is the slight problem that King Herod died in 750 A.U.C., which translates to 4 B.C. Since Herod was ostensibly alive at the birth of Jesus, we have the interesting oxymoron of Christ being alive in 4 B.C., that is, four years before the birth of Christ. In an effort to be less parochial, B.C. has been retermed B.C.E. ("Before the Christian Era," or even better, "Before the Common Era"), with A.D. renamed C.E. ("Common Era"). Even more PC is B.P. ("Before the Present"), that is, interpreted with reference to the year...
Copyright Morgan Kaufmann Publishers, Inc. 2000 under license agreement with Books24x7
