RE: gwlib/date.c bug you reported

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