The various backends feature two sets of methods for accessing time metadata:

• get_(accessed|created|modified)_time: Official Django interface. The returned datetime must be timezone aware if Django setting USE_TZ is True, else naive in the local timezone. This means the remote timezone must be known in order to be able to either (if USE_TZ=True) attach timezone information to the datetime or else (if USE_TZ=False) first shift the datetime from remote timezone to local timezone (and then remove the timezone information). Since not all backends know the remote timezone, this is not always implemented. Instead, there is also the following.
• (accessed|created|modified)_time: django-storages methods. The returned datetime is always naive. However, it is unclear in which timezone that datetime is. Those backends that know the remote timezone first shift this datetime to the local timezone (and then remove the timezone information), whereas the others leave it without timezone information in the unknown remote timezone.

Availability (✅ = implemented, ❌ = not implemented):

Options:

1. Fully implement the official Django interface. I suppose this is not possible due to missing timezone information for some backends.
2. Partially implement the official Django interface. For example, only raise NotImplementedError if USE_TZ is True but timezone information is missing. However, I doubt that conforms to the interface considering the Django documentation explicitly states that the naive datetime must be in the local timezone, which means the remote timezone must be known to be able to shift the naive datetime to the local timezone.
3. Warn about this peculiarity by explaining why the method is not implemented. For example:

   def get_modified_time(name):
       raise NotImplementedError(
           "SFTP does not provide timezone information. "
           "Use modified_time for a naive datetime instead."
   )

   This would not only inform users what is going on but document for developers that this is intended behavior.
4. Allow providing the (somehow known) remote timezone information (say, through the constructor) and only raise NotImplementedError if timezone information is missing.