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@netgroup.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 
> 
>