Not logged in - Login

Data Import / Export and Time Conversion Issues

Why are date / time data storage fields so complex to handle

One of the most complex things we encounter when it comes to designing a software product or maintaining a database system are date / time storage fields. What makes these fields so complex is that there are 24 time zones around the planet and many of those time zones change the date / time calculation for daylight savings time. So when all is said and done, getting an exact date and time for a transaction can be a bit complex but even more so when that data goes from one system to another.

General issues we see when moving data from Tracker Fluid to SAFE

Generally, we feel very confident about the date / time conversions when we move data from Fluid to SAFE. That being said, IF the data from Fluid was importing from another 3rd party system, we are seeing date / time conversion issues. The problem is that the raw data from the 3rd party system might not have been verified and was wrong when imported. If the date / time was not caught at the time of original conversion, it won't be right when coming into SAFE. Junk In = Junk Out. To reiterate, we feel very confident that the data / time coming from Fluid (when data was generated in Fluid) transfers well to SAFE.

General issues when time is not recorded as part of a date

This is a far more common problem. In SAFE, we never ignore time when recording a date / time. Time is always recorded. In Fluid we had custom fields that would allow for a date but not time. But time was in fact being recorded. We recorded the time as 00:00 but did NOT display that time in Fluid. Since SAFE requires a time, we have to put/insert something. In this case, we are adjusting each 00:00 to 12:00 (noon). This specifically can look a little weird when you are seeing a date like 1/1/2000 19:00 when in Fluid it only shows 1/1/2000. Again, we have to apply a time when importing data so that is why it's showing that way.

Error we found in the Tracker Fluid product in April 2020

For almost three years we have been preparing to sunset and expire the Tracker Fluid product. A majority of clients have already made the transition to the SAFE system but there are still quite a few that have not yet made the move. In April of 2020 we were made aware of a problem in the date / time reporting module of the Tracker Fluid system (THERE ARE NO DATE / TIME PROBLEMS WITH SAFE). The date / time being reported on all .DLL reports is off by an hour. If a transaction occurred at 2pm, it's showing 1pm.

  • Are you using .DLL reports?
    Go to File > Setup > Master Reports Setup and if you see any Report ID's that end in .DLL, you are using these reports. Specifically the 30001.dll report is a problem.

  • What if you are using 30001.dll?
    You can change to 21495.asp and this report seems to work fine. For a limited time, we are willing to modify the 21495.asp report and remove any fields that you do not want shown. Unfortunately we can only make very limited field additions. Please email if you want alterations to these reports.

  • What if you are using other .DLL reports?
    We suggest you run any of your DLL reports to see if any of the date / time fields are being reported incorrectly. Many of these reports DO NOT have date / time fields. If that is the case, you are fine. If the report is using a date / time field and the time is off, then please email and we will come up with another .asp option.

    30001.dll - Chain of Custody Report can be replaced with 21495.asp

    40001.dll - Item Submission Form can be replaced with 12138.asp OR you can remove the date field from 40001.dll.

  • Why are DLL reports a problem and not ASP reports?
    What is really weird about this issue is that historically .asp reports have been the issue and we were moving people to DLL reports to resolve. Something about the 2020 DST time conversion caused this problem. It's the first known problem with the DLL reports. The greater problem is that we investigated fixing this issue and it was going to take an almost total rewrite of the reporting system. With the production expiration on the horizon, we have made the decision to not fix this issue. That being said, we are going to work with each client to find an alternative solution for their report.

  • What if ASP reports are off by an hour?
    If you are using any ASP reports that are showing date / time off by an hour, please contact to get suggestions on another report option.

  • Is raw data in Fluid bad?
    We absolutely believe that the raw data stored in Fluid is correct. We are certain that the reporting system is what is botching up the time conversion. Again, the effort to fix is so extreme we are simply going to help people find another option for a report.