[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freetds
Subject:    [freetds] Re: Bizarre date wraparound bug
From:       "James K. Lowden" <jklowden () speakeasy ! org>
Date:       2001-10-24 4:55:03
[Download RAW message or body]

Brian Bruns wrote:
> 
> from src/tds/convert.c:
> 
> TDS_INT tds_convert_datetime(int srctype,unsigned char *src,int
> desttype,unsigned char *dest,TDS_INT destlen)
> {
> TDS_INT dtdays, dttime;
> time_t tmp_secs_from_epoch;
> 
>      switch(desttype) {
>           case SYBCHAR:
>           case SYBVARCHAR:
>           /* FIX ME -- This fails for dates before 1902 or after 2038 */
> Anybody wanna take a crack at fixing it?

Brian, 

I am working on 5 functions.  If 1 Jan 1900 + 65536 days is 6/7/2079 (I
haven't checked yet), the first one works:

bool datetime_to_tm( const TDS_DATETIME* pTdsDate, struct tm *pTm );
bool smalldatetime_to_tm( const TDS_DATETIME4* pTdsDate, struct tm *pTm
);

bool tm_to_datetime( const struct tm *pTm, TDS_DATETIME* pTdsDate );
bool tm_to_smalldatetime( const struct tm *pTm, TDS_DATETIME4* pTdsDate
);

char * tm_to_char( const struct tm *pTm, char pBuffer[] );

I don't need:
	bool char_to_tm( const char pBuffer[], struct tm *pTm );
because _string_to_tm() will do that job.  

The idea is to use the tm structure as neutral ground.  Even if the C
library wouldn't know what to do with a tm_year < 2, the structure
itself will hold any date we need.  From what I can see, we don't have
to do date arithmetic, just convert to/from string.  

--jkl

---
You are currently subscribed to freetds as: [freetds@progressive-comp.com]
To unsubscribe, forward this message to leave-freetds-113879Q@franklin.oit.unc.edu

[prev in list] [next in list] [prev in thread] [next in thread]