Reputation: 153
I am developing an application to manage shifts of operation of Internet of Things devices which can be anywhere on the planet using different time zones, I am using python, mongodb and pymongo.
As we all know, when we store a date in mongodb it automatically converts the date of our time zone to UTC by changing the time but keeping the same absolute value below.
The problem I have is that when I query the database to get the date using pymongo I get exactly the same date and time that is stored in mongodb in UTC but in my time zone without having made the conversion change;
for example, Let's suppose I create a datetime in python using the "datetime" library:
MY_TIMEZONE = pytz.timezone('America/Bogota')
datetime.now().astimezone(MY_TIMEZONE)
and I get this date in my time zone:
'2021-02-25 00:00:00-05:00'
look at -05:00 at the end
when I save that date in my mongodb collection in atlas, it transforms the date to UTC which looks like this:
'2021-02-25 05:00:00.000+00:00'
look at +00:00 at the end
So far so good, the problem comes when I query the database to obtain that same date using pymongo method "find_one"
what i get is this:
'2021-02-25 05:00:00-05:00'
look at -05:00 at the end
the same time and date as UTC but in my time zone, which in theory should not happen, I should get the date in UTC or in the local time zone but with the change. That bug can be critical in the system I'm developing.
Does anyone know what could be happening, if it is some kind of bug in the current versions? I am using python 3.8.5, pymongo 3.11.3 and mongodb 4.4.4
I have looked everywhere about this problem, but it seems that I am the only one that has happened, adding or subtracting the time difference in local is not an option, I guess I will have to choose to use timestamps to avoid this problem or another headache.
Upvotes: 3
Views: 1334
Reputation: 14490
If your application is working with multiple time zones, you should configure your system (generally preferable) or your application to use UTC as the time zone.
If you do this, you have two time zones you generally need to keep track of: UTC, which is what every timestamp is stored in, and a local time zone, which is used for output and presentation.
If you don't do this (i.e. your system and/or application time zone is anything other than UTC), you need to keep track of 3 time zones and more than 3 possible combinations of how things can go wrong:
If your application is working with a single time zone, AND all of your software is built for this correctly, you can generally assume all times are in local time and ignore time zones.
This last bit isn't always explicitly documented. For example in Ruby, the base driver timezone behavior is described here and it doesn't say that all times are returned in local time zone. Mongoid documentation has a more extensive treatise of time zones, because they are explicitly configurable.
For pymongo I suggest reviewing the entirety of documentation carefully looking for equivalent statements (and make sure you review the bson (de)serialization docs as well), and failing that you might need to read the source code to ascertain behavior.
In any event, working with multiple time zones when your system/application time zone is not UTC is really more difficult than it should be and I don't recommend it (if not for yourself, then whoever will have to work with your code after you).
Upvotes: 2