No subject


Fri May 2 19:13:14 EDT 2003


/* FIX ME -- This fails for dates before 1902 or after 2038 */

(jkl, faq entry for this thing?)

The current implementation uses strftime() which accepts as an input the 
number of seconds since the epoch (Jan 1 1970) which being a signed 32bit
integer gives the date range above.  The fix will require an 
implementation of strftime (or something close) that handles the entire 
range of TDS datetime datatype.  Of course if someone wants to point me at 
an implemenation under a usuable license that I can hork, we can have this 
fixed in a jiffy (datetime humor ;-)

Cheers,

Brian
		
On Tue, 4 Dec 2001, Steven J. Backus wrote:

>   Just noticed this (on sqsh 2.1 and freetds 0.53pre3).  Birth_date
> is of type datetime:
> 
> 111 episun12-> sqsh
> Password: 
> [21] episun7.ged.1> select birth_date from individual where id = 9743798
> [21] episun7.ged.2> go
>  birth_date         
>  -------------------
>  Dec 01 2023 06:28AM
> 
> (1 row affected)
> [22] episun7.ged.1> 
> 
> Using sybase's isql (no freetds) the correct date shows up:
> 
> 157 episun7-> isql
> Password: 
> [21] episun7.ged.1> select birth_date from individual where id = 9743798
> [21] episun7.ged.2> go
>  birth_date         
>  -------------------
>  Oct 25 1887 12:00AM
> 
> (1 row affected)
> [22] episun7.ged.1> 
> 




More information about the FreeTDS mailing list