Commit Graph

15 Commits

Author SHA1 Message Date
Thomas G. Lockhart c06331a47d Change a few routine names back to full length now that pg_proc allows
names over 16 characters. datet_datetime() -> datetime_datetime(), etc.
1997-12-23 19:23:09 +00:00
Thomas G. Lockhart 4fa25b8c99 Shorten routine names to <= 16 characters to fit in pg_proc table. 1997-10-25 05:22:58 +00:00
Thomas G. Lockhart 8fe55efd7b Support special values 'now', 'current', etc on output. 1997-10-09 05:02:17 +00:00
Thomas G. Lockhart 31174f11d0 Remove difftime() calls.
Still uses time_t declarations, but most code will be changed for next release.
1997-09-16 16:12:55 +00:00
Bruce Momjian 59f6a57e59 Used modified version of indent that understands over 100 typedefs. 1997-09-08 21:56:23 +00:00
Bruce Momjian 319dbfa736 Another PGINDENT run that changes variable indenting and case label indenting. Also static variable indenting. 1997-09-08 02:41:22 +00:00
Bruce Momjian 1ccd423235 Massive commit to run PGINDENT on all *.c and *.h files. 1997-09-07 05:04:48 +00:00
Bruce Momjian 4e9e00cb68 Fix for sunos4 difftime() call. 1997-08-19 21:47:07 +00:00
Bruce Momjian 5a38a119b2 Remove sparc dir, add difftime macro for sunos. 1997-07-28 00:13:39 +00:00
Thomas G. Lockhart 8507ddb9c6 Use common parser and encoder for timestamp data type.
Remove older date and time code (retain NEW_DATE_CODE and NEW_TIME_CODE).
Use common encoder for date and time.
Fix datetime +/- timespan math bug.
1997-07-01 00:22:46 +00:00
Thomas G. Lockhart 64d9b50893 Fix timezone manipulation code to avoid crashes on some machines.
Add type conversion functions for floating point numbers.
Check for zero in unary minus floating point code (IEEE allows an
 explicit negative zero which looks ugly in a query result!).
Ensure circle type has non-negative radius.
1997-05-11 15:11:47 +00:00
Marc G. Fournier 4bc578eb83 From: "D'Arcy J.M. Cain" <darcy@druid.net>
Subject: [HACKERS] timestamp.c changes

I sent in changes previously and they were rejected because they didn't
follow ANSI spec.  Here is the input part of the changes again.  Even
though it allows more flexibility for inputting different formats, it
is also backwards compatible with the standard version.  I have also
not changed the output format so it will still output the ANSI forms.
Is this acceptable to everyone?
1997-04-03 19:58:11 +00:00
Marc G. Fournier 2ab34dfe1a From: Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
Subject: [HACKERS] More date time functions

Here are some additional patches mostly related to the date and time
data types. It includes some type conversion routines to move between
the different date types and some other date manipulation routines such
as date_part(units,datetime).

I noticed Edmund Mergl et al's neat trick for getting function overloading
for builtin functions, so started to use that for the date and time stuff.
Later, if someone figures out how to get function overloading directly
for internal C code, then we can move to that technique.

These patches include documentation updates (don't faint!) for the built-in
man page. Doesn't yet include mention of timestamp, since I don't know
much about it and since it may change a bit to become a _real_ ANSI timestamp
which would include parser support for the declaration syntax (what do you
think, Dan?).

The patches were developed on the 970330 release, but have been rebuilt
off of the 970402 release. The first patch below is to get libpq to compile,
on my Linux box, but is not related to the rest of the patches and you can
choose not to apply that one at this time. Thanks in advance, scrappy!
1997-04-02 18:36:24 +00:00
Marc G. Fournier 070381482f From: "D'Arcy J.M. Cain" <darcy@druid.net>
Subject: [HACKERS] backend/utils/adt/timestamp.c

Back to this timezone stuff.  The struct tm has a field (tm_gmtoff) which
is the offset from UTC (GMT is archaic BTW) in seconds.  Is this the
value you are looking for when you use timezone?  Note that this applies
to NetBSD but it does not appear to be in either ANSI C or POSIX.  This
looks like one of those things that is just going to have to be hand
coded for each platform.

Why not just store the values in UTC and use localtime instead of
gmtime when retrieving the value?

Also, you assume the time is returned as a 4 byte integer.  In fact,
there is not even any requirement that time be an integral value.  You
should use time_t here.

The input function seems unduly restrictive.  Somewhere in the sources
there is an input function that allows words for months.  Can't we do
the same here?

There is a standard function, difftime, for subtracting two times.  It
deals with cases where time_t is not integral.  There is, however, a
small performance hit since it returns a double and I don't believe
there is any system currently which uses anything but an integral for
time_t.  Still, this is technically the correct and portable thing to do.

The returns from the various comparisons should probably be a bool.
1997-03-25 09:25:33 +00:00
Marc G. Fournier 94094c0569 Missed another tar file... :( 1997-03-14 05:58:13 +00:00