AnsweredAssumed Answered

Why does DLT modify datetime import definition

Question asked by DETCOG_GIS on Oct 6, 2020
Latest reply on Oct 13, 2020 by avezina-esristaff

The ExecuteDataLoad tool, when run in python at least, appears to overwrite the datetime module imported by import arcpy.  This sample code hopefully describes the issue:

import arcpy

import datetime
#import datetime appears to be part of import arcpy
#but for readability of code, you can include it, though it's redundant

#even if we exclude "import datetime", the following line shows it imports the module
print(datetime)
#returns <module 'datetime' from 'C:\\...\\ESRI\\conda\\envs\\arcgispro-py3-clone\\lib\\datetime.py'>

#so you can do things like the following:
print(datetime.datetime.now())

#Now lets run the data loading tools
arcpy.dlt.ExecuteDataLoad(r'...\dataloadingworkspace\DataReference.xlsx')

#However, after running the ExecuteDataLoad tool, datetime is modified, so now:
print(datetime)
#returns <class 'datetime.datetime'>

#which means the code
print(datetime.datetime.now())
#that previously worked, suddenly now
#returns AttributeError: type object 'datetime.datetime' has no attribute 'datetime'

 

The problem is, first off, this is confusing as can be, and makes reading/following the code rather confusing that there's an undocumented shift in what is defined as datetime.  However, second, and more worrisome, is the fact that I have to assume import arcpy includes an import of datetime for a reason.  What I'm getting at is, if arcpy assumes datetime will be the datetime module and calls like datetime.datetime.now() (and others) will work in that specific syntax.  Then isn't there a potential that a tool, only callable within arcpy, modifying that core assumption, could cause issues with other parts of arcpy...?

 

Am I over-thinking this or missing something?

Outcomes