Hi Stipe, This change was made to fix a problem with EMI2 timestamps. The EMI2 driver gets the timestamp from the UCP frame, and calls date_convert_universal(). The problem is that EMI2 timestamps have 1-based months, and date_convert_universal() expects 0-based months (date.c v1.8). So it returns a timestamp that is 1-month ahead, or even worst, it tries to access monthstart[12] wich is out of bounds and dumps core.
I suggested changing date_convert_universal() to accept 1-based months: that fixed EMI2 behaviour, but as you can see, broke other things: smsc_http.c for example calls date_convert_universal() with 0-based months. And now checks/check_date complains as well. So IMHO the best solution is to maintain date.c v1.8, and fix the EMI2 behaviour in smsc_emi2.c, to properly build timestamps for MO messages. I think we should consider this EMI2 MO timestamps mis-behavior as a release show-stopper. Angel Fradejas. -----Mensaje original----- De: Stipe Tolj [mailto:[EMAIL PROTECTED]] Enviado el: martes 26 de marzo de 2002 11:50 Para: Angel Fradejas CC: [EMAIL PROTECTED] Asunto: gwlib/date.c bug you reported Hi Angel, can you please see http://www.kannel.3glab.org/cgi-bin/viewcvs.cgi/gateway/gwlib/date.c.diff?r1 =1.8&r2=1.9 and tell me exactly why this change was necessary? I'm getting failure reports now from checks/check_date that does reverse date conversion. Until we have not cleanly resolved this, I'm going back to revision 1.8 to make the check routines happy. Stipe [EMAIL PROTECTED] ------------------------------------------------------------------- Wapme Systems AG M�nsterstr. 248 40470 D�sseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de ------------------------------------------------------------------- wapme.net - wherever you are
