Re: PG sql string -> time_t

OK, I understand now. But I say that most people don't (or shouldn't)
want to actually use the time in epoch format. Since I started using
PostgreSQL the I've rarely needed to use EXTRACT(epoch ..) if at all,
because:

For formatting dates for user display, its best to let PostgreSQL do all
that, and the C programmer will simply format it how he needs it when he
writes his SQL queries, using to_char(). Each application you write
will usually require date/time display in a different format each time.

PostgreSQL handles dates, times, timezones, adding and subtracting times
in a much easier way than you programming it yourself, and in the rarer
case the programmer really needs it in epoch format he can just use
EXTRACT(epoch ..) in a query.

If you still want to do, I think the easiest way would be to parse the
string you get from PostgreSQL and use the C library's mktime().

- Andrew

> -----Original Message-----
> From: Bo Lorentsen [mailto:bl(at)netgroup(dot)dk]
> Sent: Wednesday, 19 December 2001 1:32 AM
> To: Andrew Snow
> Subject: RE: [GENERAL] PG sql string -> time_t
>
>
> On tir, 2001-12-18 at 15:21, Andrew Snow wrote:
> > I don't understand... extract lets you get date, time, and
> timestamp,
> > and interval, into time_t format.. what else do you need?
> Hmm, sorry I'm not more clear (not native you know), I am
> working an a more generic database interface (in C++) for the
> PostgreSQL database (and one or two others), modelled much
> like the JDBC module but in C++. When the user gets a
> resultset from my code, from a query that is, I like to be
> able to pass back a more "date computing" friently entity
> than a string (In C this is the time_t).
>
> I could bemand the user to write some special kind of
> Postgres SQL, but I prefere to do it the "right" way, by
> interpreting the date/time string and passing back a time_t
> (or maby a DateTime class later). By doing this the user does
> not have to think about what is going on, and will be able to
> make queries that is more "simple", and easy to read (and debug).
>
> Did that help ? :-)
>
> /BL
>
>