-
Notifications
You must be signed in to change notification settings - Fork 38
[FIX] - catch missing orgbook entity and improve logging #3301
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
return datetime(date.year, date.month, date.day, 0, 0, 0, tzinfo=ZoneInfo("UTC")).isoformat() | ||
def convert_date_to_iso_datetime(datetime: datetime) -> str: | ||
return datetime( | ||
datetime.year, datetime.month, datetime.day, 0, 0, 0, tzinfo=ZoneInfo("UTC")).isoformat() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have to check, just because we have a million issues with UTC times- this converts the datetime to UTC, not tells it that the timezone it has is UTC, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
datetime objects are natively timezone-unaware.
the python language is deprecating some of these methods in favour or producting timezone-aware datetime objects
well formed VCDM credentials required timezone codes, i could just append T00:00:00
to the string, but this is a more pythonic way to do that and is better understood by future devs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What that means is existing datetime objects based on UTC don't know they are based on UTC, they are date+time with no timezone information. it's up to the code to know that it's based on UTC, or maybe postgres is automatically adding UTC information?
it's probably something that should become it's own task. to update the python to start using the new timezone-aware methods and classes, update the validators to require timezone-aware objects (or add it), then update remaining datetime values to have timezone information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Sounds good. The db does automatically save it as UTC. I appreciate the documentation!
ensure factory is producing a datetime and not a date
This line scares me.... mds/services/core-api/app/api/mines/permits/permit_amendment/models/permit_amendment.py Line 123 in fffc9aa
|
clicks git blame On the bright side: you've learned something in the last 3 years. |
that's not funny at all. ~~it implies that dates and datetimes are both being used in the code, but the original intention was to only ever store datetime objects. ~~ this one hurts, and on a friday no less. |
pmt_appt_start_date = pmt_appt.start_date.date() | ||
else: | ||
print(type(pmt_appt.start_date)) | ||
print("WHAT?") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😂
Miiiiiight want something else for an error log message. A little more context for the rest of us.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great! Thanks for cleaning up those date <-> datetime inconsistencies 🙌
No description provided.