MEAN stack mongoose saves datetime with "Z" timezone wrong - node.js

in Mongodocs, it is said that datetimes with specified "Z" timezone at the end are saved as "UTC" datetime format..
https://docs.mongodb.com/manual/reference/method/Date/
I created some sample time data in Python:
now=str((datetime.datetime.now()).isoformat())+'Z'
then=str((datetime.datetime.utcnow()+datetime.timedelta(0,one_week_in_seconds)).isoformat())+'Z'
I used datetime.now() and datetime.utcnow() and appended 'Z' on both...
this is what I get:
'now': '2018-07-10T11:06:05.512484Z',
'then': '2018-07-17T09:06:05.512484Z',
I am now using MEAN stack with Node/Express and mongoose (ODM) Driver to make my schema models in the database. When I push the data via some router middleware to my mongoDB Database, the two fields have mongoose "Date" format. However, for both fields it creates an ISODate time format...:
"now" : ISODate("2018-07-10T09:02:01.410Z"),
"then" : ISODate("2018-07-17T09:02:01.410Z"),
I think thats a bug, normally, if "Z" is specified, it should create the specified time in ISO-Format, which it is here, but as I have created the time in local-time format and appended a "Z" in the first case ("now"), the time should be saved as 'now' : ISODate("2018-07-10T11:06:05.512484Z") without modifying /
converting from local to UTC time or not?

if you want to save specific country timezone and if you are using moment then it is easy to manage
below link will help to you
Updating time offset with moment().utcOffset()

Related

PostgreSQL - how to convert timestamp with timezone to timestamp without timezone

In my PostgreSQL database, the datetime stored as 2022-05-10 10:44:19+08 and when I get
the datetime by using the sequelize, it will give in format:: 2022-05-10T02:44:19.000Z.
So, my question is how to convert to 2022-05-10 10:44:19 ?
Thanks in advance.
There is a direct dependence on the time of your server. Therefore, depending on what you want to get, you can use different options.
Here is a dbfiddle with examples

Pymongo Query for Date is failing

I have a query that works fine in mongodb compass, but the moment I bring it over into Jupyter it breaks. The issue is something to do with the date filter.
I have tried both:
cursor = prod_db.my_collection.find({"date": {"$eq": "new Date('2021-04-26')"}, "type": "Regular"})
as well as
cursor = prod_db.my_collection.find({"date": "new Date('2021-04-26')", "type": "Regular"})
If I remove the date query, I get a return that I would expect, which validates that the db connection is set up properly and that the "type" filter is valid. What am I missing here?
new Date is the date keyword for MongoShell.
You should replace it with python's built-in datetime package.
from datetime import datetime
cursor = prod_db.my_collection.find({"date": datetime(2021, 4, 26), "type": "Regular"})
Issues mapping date columns across python and Mongo happens primarily because Mongo stores the date as a JavaScript date object and then wraps the ISODate format around it. However if the date values that we are trying to pass from python onto mongo is in datetime format ( like #hhharsha36 mentioned above) one should be good
I found this article helpful when I was going through some hellish time using dates from pandas and python variables and using that to query/insert/update in Mongo : (https://medium.com/nerd-for-tech/how-to-prepare-a-python-date-object-to-be-inserted-into-mongodb-and-run-queries-by-dates-and-range-bc0da03ea0b2)

DateTime adjustment when reading TDMS files from Python

I have a TDMS file with a bunch of DateTime values with relevant instrumentation data.
The issue I am having is:
TDMS file >>>> Python Reads
4/20/2021 12:00:01 AM >>>> 2021-04-20 04:00:00.597573
4/20/2021 8:00:01 PM >>>> 2021-04-21 00:00:00.570708
This is messing up transfers to the database because it is not accurate.
This is my code:
dfscaled = tdmsfile.__getitem__("Data (Scaled)").as_dataframe()
for index, row in dfscaled.iterrows():
print(row["Timestamp"])
I am using the NPTDMS library. Any ideas on how to fix this?
So I ended up contacting the author and he was helpful enough to send a response:
TDMS files internally store times in UTC. You don't say how you're
getting the values in the "TDMS file" column but I assume this is from
a program that converts times into your local timezone to display
them. There is an example of how to convert UTC times from a TDMS file
into your local timezone in the documentation.
If you are storing these times in a database though, I would strongly
recommend you store times in UTC rather than your local timezone as
local times can be ambiguous due to daylight savings changes, and UTC
is easily understood from anywhere in the world without having to know
the local timezone where the data originated.
If you still feel like making the change from UTC to EST then this should do it:
fmt = "%Y-%m-%d %H:%M:%S.%f"
x=pd.to_datetime(row["Timestamp"]).tz_localize('UTC').tz_convert('US/Eastern').strftime(fmt)
dtm=pd.to_datetime(x[:-3])
print(dtm)

How to supress warning: Datetime with no tzinfo will be considered UTC?

I have the following code which am using to monitor Azure ADF pipeline runs. The code uses 'RunFilterParameters' to apply a date range filter in extracting run results:
filter_params = RunFilterParameters(last_updated_after=datetime.now() - timedelta(1), last_updated_before=datetime.now() + timedelta(1))
query_response = adf_client.activity_runs.query_by_pipeline_run(resource_group, adf_name, row.latest_runid,filter_params)
The above works ok, however it is throwing a warning:
Datetime with no tzinfo will be considered UTC
Not sure how to add timezone to this or just suppress the warning?
Please help.
"no tzinfo" means that naive datetime is used, i.e. datetime with no defined time zone. Since Python assumes local time by default for naive datetime, this can cause unexpected behavior.
In the code example given in the question, you can create an aware datetime object (with tz specified to be UTC) like
from datetime import datetime, timezone
# and use
datetime.now(timezone.utc)
If you need to use another time zone than UTC, have a look at zoneinfo (Python 3.9+ standard library).

Python timezone conversion adding minutes to the hour?

So I'm trying to convert a bunch of hours (10:00:00, 14:00:00, etc) from a given timezone to UTC.
When I do so, I keep maddeningly getting things back like "15:51:00".
When you get to that line, and print what value it's using, it's using something like:
1900-01-01 12:00:00-05:51
Which is fine, except for the -05:51 bit. I have no idea why that -05:51 is there, and it's causing me problems. UTC conversion is hour to hour, yes? I think it's got something to do with my timezone conversions, but I really don't get why they would be doing that.
Here's a minimal example that has the same erroneous output; it returns 15:51:00 when it should just return a flat hour, no minutes.
import datetime
from dateutil import tz
jj = datetime.datetime.strptime("10:00:00", "%H:%M:%S")
tzz = tz.gettz('US/Central')
def constructstring(tzz,x):
inter2 = x.replace(tzinfo=tzz) #ERROR HAPPENS HERE (I'm pretty sure anyways)
inter3 = inter2.astimezone(tz.tzutc())
return inter3
print(constructstring(tzz,jj).strftime("%H:%M:%S"))
You are not specifying a date when you create the jj datetime object, so the default date of 1900-01-01 is used. Timezones are not fixed entities; they change over time, and the US/Central timezone used a different offset back in 1900.
At the very least, use a recent date, like today for example:
# use today's date, with the time from jj, and a given timezone.
datetime.datetime.combine(datetime.date.today(), jj.time(), tzinfo=tzz)
If all you need is a time, then don't create datetime objects to store those; the datetime module has a dedicated time() object. I'd also not use strftime() to create objects from literals. Just use the constructor to pass in integers:
jj = datetime.time(10, 0, 0) # or just .time(10)
Other good rules of thumb: If you have to deal with dates with timezones, try to move those to datetime objects in UTC the moment your code receives or loads them. If you only have a time of day, but still need timezone support, attach them to today's date, so you get the right timezone. Only convert to strings again as late as possible.

Resources