Closed deronnax closed 3 months ago
Attention: Patch coverage is 75.00000%
with 3 lines
in your changes are missing coverage. Please review.
Project coverage is 95.18%. Comparing base (
078d0ca
) to head (547d5d7
). Report is 7 commits behind head on main.
Files | Patch % | Lines |
---|---|---|
appointment/views.py | 62.50% | 3 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
I am fine with the PR. We can merge it if you are fine too.
And since we don't manually manipulate timezone anymore, we don't use pytz anymore and we can now remove it. I had to edit a commit already committed for the git history to remain clean sorry, you will probably have to do a git pull --rebase
. Sorry for the inconvenience, I do this sparingly I promise.
And since we don't manually manipulate timezone anymore, we don't use pytz anymore and we can now remove it. I had to edit a commit already committed for the git history to remain clean sorry, you will probably have to do a
git pull --rebase
. Sorry for the inconvenience, I do this sparingly I promise.
Don't worry, git manipulations is part of my daily routine nowadays because of my line of work, learning it the hard way.
I am fine with the PR. We can merge it if you are fine too.
I'll try to fix the codecov error and then we merge. I'm fine with it too. Wondering if it's not time to do a 3.4.0 release...
I think it's worth doing a 3.4.0 release: when you change a lot of things, it's good to release often otherwise a release brings too many changes and people never migrate.
I think it's worth doing a 3.4.0 release: when you change a lot of things, it's good to release often otherwise a release brings too many changes and people never migrate.
It's just this line in init.py file to change. GitHub Actions will take care of the rest and create the release.
Current time zone handling of django-appointment is incorrect.
settings.TIME_ZONE
is a fallback from the past for when correct time zone support was not present in Django. Now timezones works perfectly fine and you are not suppose to use the TIME_ZONE. Just useget_current_timezone()
and let django handle the current user's timezone for you.