DT_DateTimeAddSeconds & DT_DateTimeSubSeconds misbehave
issueid=343 14-02-2012 13:57
Junior Member
Number of reported issues by TomC: 2
DT_DateTimeAddSeconds & DT_DateTimeSubSeconds misbehave
Give wrong result with dates of 12-30-2012 & 12-31-2012 respectively

DT_DateTimeAddSeconds & DT_DateTimeSubSeconds misbehave with dates of 12-30-2012 & 12-31-2012 respectively
With the following test harness DT_DateTimeAddSeconds gives "00--01-2012 942941:28:48" and DT_DateTimeSubSeconds gives "00--01-2012 942965:19:44"

The following test harness shows the problem - just run it in debug mode & set a breakpoint on "TestStop=0"

Uses "UI"
  Uses "File"
  Uses "DT"
  Uses "OS"
  Uses "TBGL"
    Local sDate As String
  Local sTime As String 
  Local TempSecondsABS As Number 
  Local Temp_CAD_DateTimeAddSecs As String  
  Local Temp_CAD_DateTimeSubSecs As String  
  Dim TempStop As Number
  
sDate = "12-30-2012"
sTime = "00:00:00" 
TempSecondsABS = 272
Temp_CAD_DateTimeAddSecs = DT_DateTimeAddSeconds(sDate, sTime, TempSecondsABS)     
TempStop = 0 
sDate = "12-31-2012"  
Temp_CAD_DateTimeSubSecs = DT_DateTimeSubSeconds(sDate, sTime, TempSecondsABS)     
TempStop = 0
Issue Details
Issue Number 343
Project thinBasic
Category Unknown
Status Unconfirmed
Priority 2
Affected Version 1.8.9
Fixed Version (none)
Milestone (none)
Users able to reproduce bug 1
Users unable to reproduce bug 0
Assigned Users (none)
Tags (none)




15-02-2012 11:24
thinBasic author
Thanks a lot.
I'm quite ready to release a new thinBasic beta version. I will try to fix it as soon as possible.

27-02-2012 18:37
Junior Member
Thanks.
I've done a bit more testing & it seems to affect several more DT routines (probably all the ones which do things with seconds).
I've also tried all of my older versions of the DT module & they all seem to (mis)behave in a similar way.
But it looks like it only affects those two dates and only on Leap Years!! (which probably explains how it survived so long without being spotted)
Hope that helps give you a lead on where it's going wrong. Let me know if I can be of help fixing it.

28-02-2012 22:42
thinBasic author
Thanks a lot Tom.
I'm a bit short in time due to heavy work load but I had time during last week.end to have a look at DT module and the more I see it, the more I have the temptation to re-code it from very basis.
DT module was written some years ago by a friend of mine. Looking now at source code I think there are some black holes in the general idea of it.
I think the functions that transform a date to second and back are applying different philosophy in considering how many seconds a date has. Some functions consider a date like having 00:00:00 time and other are considering a date as having 23:59:59 time.
I need to review all the functions using the same algo.

In the meantime another friend of Mine (Simone, a forum user) send me a new library he developed on dates.
I'm checking it looking if I can switch to this one keeping old DT module syntax

will let you know, it will take some time.
Maybe at the end I will in the position to publish source code of the module ... will see.

Ciao
Eros

10-03-2012 13:33
Junior Member
Hi Eros,
Thanks
Replacements for DT_DateTimeAddSeconds, DT_DateTimeSubSeconds, DT_DateToSec, DT_SecToDate

I've done some more investigations and it looks like the DT routines that move between “Time” and seconds, work fine so long as you don't give them more than a days worth of seconds.
But the DT Routines that move between “Date” and seconds give errors sometimes. So I've written some quick replacements for the four above. They're a bit “quick and nasty” in that they don't do any validation on the date and they only accept the date in mm-dd-yyyy format (I figure that they need to be quick & the calling prog can do any validation that's needed.).
They take 1 Jan 1600 as the base date and work on the number of seconds to the START of the day i.e. DateToSec (“01-01-1600”) will return zero seconds, DateToSec (“01-02-1600”) will return 86400 seconds. The days run from “00:00:00” to “23:59:59”.

The new routines are named MYDT_ …. and are called exactly the same as their DT_... counterparts. (I figure that it should be easy to do a global edit of the calling program from “MYDT_” to “DT_” to get rid of them when the time comes).

I've attached a couple of files:
MYDT.tbasic which contains the routines and
MYDT_DateTimeTestHarness.tbasic which shows the tests I ran and is an example of how to call them

And finally a quick warning for anyone who might use them – I think they work, but when I started to use them for real I did find a couple of errors that had slipped through testing. They're now fixed, but there might be some more, so please feel free to do extra testing & let me know if something misbehaves.

10-03-2012 13:33
Issue Changed by TomC
  • Attachment MYDT.tbasic uploaded

10-03-2012 13:33
Issue Changed by TomC
  • Attachment MYDT_DateTimeTestHarness.tbasic uploaded

10-03-2012 13:35
Junior Member
Here arethe attachments

13-03-2012 15:59
Issue Changed by TomC
  • Attachment MYDT.tbasic uploaded

13-03-2012 16:00
Issue Changed by TomC
  • Attachment MYDT_DateTimeTestHarness.tbasic uploaded

13-03-2012 16:00
Junior Member
Found a bug (in leap year processing!!) so I've just uploaded a fixed version

13-03-2012 22:41
Super Moderator
Thanks a lot for the test scripts, they help a ton in testing!


Petr

+ Reply