Update khal to Follow PEP495 Removing Deprecation Warnings #1093

pjkaufman · 2021-10-22T12:18:50Z

When running khal ... or ikhal ... an issue would arise where warnings about deprecated functions being used (see #1092). This was not a critical change that was needed, but it was more to remove the warnings as an eye sore for myself and those that would not be able to do so on their own.

Changes Made:

Updated AUTHORS.txt as per the documentation for contributing
Imported and used ZoneInfo in order to assign a timezone where the warnings were being thrown (2 locations in khalendar.py and event.py though I decided to add two more locale format updates in one of the methods here)

I had to convert the timezone info to a string just in case it was something else because when I did not do so, I got errors.
Also, I did initially try to change all of the localize methods to use ZoneInfo, but that started causing test cases to fail for certain files, so I opted to just fix the visible issue.

I am newish to python, but have used it to write programs or scripts before. So please let me know if there is something I missed, a better way to do things, or if this PR should be more extensive.

Here is the source I am using for determine how to convert code to the PEP495: https://pytz-deprecation-shim.readthedocs.io/en/latest/migration.html

Note: there is no longer a built in list of transition dates for daylight savings times, so it will need to be decided how to handle this especial since the standards for this have changed several times.

pjkaufman · 2021-10-22T12:31:26Z

Correct me if I am wrong, but it looks like pre-commit.ci has not been added to the actual ci yet since the PR is currently pending a merge. Is there a way I should modify my branch to account for this, or do I need to wait on that other PR which has been waiting for approval for 2 months?

Thank you for letting me know!

pjkaufman · 2021-10-22T12:34:34Z

Note: I did miss the khal at method and need to check and see what needs to be done for that.

pjkaufman · 2021-10-22T16:32:22Z

Note: I did miss the khal at method and need to check and see what needs to be done for that.

This was taken care of earlier. I am now just waiting on guidance regarding the pre-commit issue.

pjkaufman · 2021-10-23T02:02:34Z

I just realized that there are other places where these warnings are displayed as well. I am going to try to fix as many of them as I can, but this may be above my understanding level. The timezone change is simple enough, but the problem seems to arise when dealing with all of these different icalendar attributes and how the new way of doing these things should be done in the current standard.

khal/khalendar/event.py

khal/khalendar/khalendar.py

pjkaufman · 2021-10-23T15:37:32Z

@WhyNotHugo , PEP495 no longer has transition dates for when going into or out of daylight savings (https://pytz-deprecation-shim.readthedocs.io/en/latest/migration.html#semantic-differences-between-is-dst-and-fold). How would we like to handle that?

Possible Solutions:

I can try to estimate the DST days for years since 2007 using an algorithm for the standards set then (https://www.timeanddate.com/time/change/usa)

We could extend this to other date ranges as needed

we can hard code our own list of when DST happened in each year

Also BST would need a similar solution.

What do you think about this?

WhyNotHugo · 2021-10-23T15:45:04Z

Though I would think suppressing dependency print output would probably be bad practice.

Agreed. Warnings in dependencies need to be addressed in the dependencies themselves. Problem is, some of our dependencies are growing stale or not supporting modern pythons.

WhyNotHugo · 2021-10-23T15:52:02Z

On Sat, 23 Oct 2021, at 17:37, Peter Kaufman wrote: @WhyNotHugo <https://github.com/WhyNotHugo> , PEP495 no longer has transition dates for when going into or out of daylight savings (https://pytz-deprecation-shim.readthedocs.io/en/latest/migration.html#semantic-differences-between-is-dst-and-fold). How would we like to handle that? Possible Solutions: 1. I can try to estimate the DST days for years since 2007 using an algorithm for the standards set then (https://www.timeanddate.com/time/change/usa) * We could extend this to other date ranges as needed 1. we can hard code our own list of when DST happened in each year Also BST would need a similar solution. What do you think about this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1093 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFSNOZECOMZJE5LDQMJRLTUILJENANCNFSM5GQNTTHA>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

Sorry, I'm not fully understanding here. What exactly is it that's missing on PEP495?

pjkaufman · 2021-10-23T20:26:26Z

On Sat, 23 Oct 2021, at 17:37, Peter Kaufman wrote: @WhyNotHugo https://github.com/WhyNotHugo , PEP495 no longer has transition dates for when going into or out of daylight savings (https://pytz-deprecation-shim.readthedocs.io/en/latest/migration.html#semantic-differences-between-is-dst-and-fold). How would we like to handle that? Possible Solutions: 1. I can try to estimate the DST days for years since 2007 using an algorithm for the standards set then (https://www.timeanddate.com/time/change/usa) * We could extend this to other date ranges as needed 1. we can hard code our own list of when DST happened in each year Also BST would need a similar solution. What do you think about this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1093 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFSNOZECOMZJE5LDQMJRLTUILJENANCNFSM5GQNTTHA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Sorry, I'm not fully understanding here. What exactly is it that's missing on PEP495?

@WhyNotHugo
The issue is located here: https://github.com/pimutils/khal/blob/master/khal/khalendar/event.py#L856-L901
The first issue is that we are using the transition times defined by pytz which no longer exist when the timezone passed in is a ZoneInfo. Here is where we get that information currently: https://github.com/pimutils/khal/blob/master/khal/khalendar/event.py#L866-L868.
Then we use _tzinfos to help determine our RDATE and timezone information for our events. I am not sure what the equivalent is in PEP495 so we might not be able to use the current system for determining BST and DST. If we want to fix this, we could have to swap over to a new way of doing things.

The nice thing is that time additions to a datetime will show a change in fold, but will not help us with our checks in this are of code (at least not that I am aware of).

Does that help clarify the issue?

setup.py

pjkaufman · 2021-10-25T00:57:36Z

I think I have something for DST times that are newer than 2007 (I think I can add other date ranges as well, it is just that the algorithm for doing so will need to be modified. I am having issues with DST transition times. Is there a way outside of pytz to do determine its transition times?

Here is what I am thinking for the new create_timezone method:

def create_timezone(tz, first_date=None, last_date=None):
...
    # TODO last_date = None, recurring to infinity

    first_date = dt.datetime.today() if not first_date else to_naive_utc(first_date)
    # TODO: determine if there is a way to do this for BST pjk
    # check to see if timezone is a part of dst by checking if before or after the transition it has an offset
    if first_date.dst() == dt.timedelta(0) and first_date.replace(fold= 1).dst() == dt.timedelta(0):
        return _create_timezone_static(tz)
    
    last_date = dt.datetime.today() if not last_date else to_naive_utc(last_date)
    timezone = icalendar.Timezone()
    timezone.add('TZID', tz)

    transition_times = _get_transition_dates_dst_for_daterange(tz, first_date.replace(tzinfo=tz), last_date.replace(tzinfo=tz))
    timezones = {}
    for index in range(1, len(transition_times)):
        name = transition_times[index].tzname()
        if name in timezones:
            ttime = transition_times[index].replace(tzinfo=None)
            if 'RDATE' in timezones[name]:
                timezones[name]['RDATE'].dts.append(
                    icalendar.prop.vDDDTypes(ttime))
            else:
                timezones[name].add('RDATE', ttime)
            continue

        if transition_times[index].dst() != dt.timedelta(0):
            subcomp = icalendar.TimezoneDaylight()
        else:
            subcomp = icalendar.TimezoneStandard()
        
        subcomp.add('TZNAME', name)
        subcomp.add(
            'DTSTART',
            tz.fromutc(transition_times[index]).replace(tzinfo=None) # Note: for some reason this is using EDT instead of the zone info name for the value here, I need to figure out why as this is incorrect
        )
        
        subcomp.add('TZOFFSETTO', transition_times[index].utcoffset())
        subcomp.add('TZOFFSETFROM', transition_times[index - 1].utcoffset())
        timezones[name] = subcomp

    for subcomp in timezones.values():
        timezone.add_component(subcomp)

    return timezone

Here is the DST algorithm (this is more a proof of concept than an actual final algorithm):

def _get_transition_dates_dst_for_daterange(tz, start_date, end_date):
    #TODO: add date range based algorithms for determining the correct dst time zones where rules exist pjk
    if start_date.year < 2007:
        msg = (
                f"Cannot work with start dates prior to 2007 at this time. Date supplied was" + str(start_date) + "."
            )
        logger.fatal(msg)
        raise FatalError(  # because in ikhal you won't see the logger's output
            msg
        )

    year = start_date.year-1
    years = []
    while year <= end_date.year+1:
        years.append(year) 
        year +=1

    index_of_first_transition_before_start_date = 0
    index = 0
    transition_times = []
    for year in years:
        marchCal = calendar.monthcalendar(year, 3)
        first_week  = marchCal[0]
        second_week = marchCal[1]
        third_week  = marchCal[2]

        if first_week[calendar.SUNDAY]:
            dst_begins = second_week[calendar.SUNDAY]
        else:
            dst_begins = third_week[calendar.SUNDAY]

        dst_start = dt.datetime(year, 3, dst_begins, 2, tzinfo= tz)
        transition_times.append(dst_start)
        if dst_start < start_date:
            index_of_first_transition_before_start_date = index
        
        if end_date < dst_start:
            break
        
        novemberCal = calendar.monthcalendar(year, 11)
        first_week  = novemberCal[0]
        second_week = novemberCal[1]

        if first_week[calendar.SUNDAY]:
            dst_ends = first_week[calendar.SUNDAY]
        else:
            dst_ends = second_week[calendar.SUNDAY]
        
        dst_end = dt.datetime(year, 11, dst_ends, 2, tzinfo= tz)
        transition_times.append(dst_end)
        if end_date < dst_end:
            break
        
        index +=1
    
    return transition_times[index_of_first_transition_before_start_date:]

RonnyPfannschmidt · 2021-10-28T14:44:44Z

as the vtimezone stuff seems daunting i started a conversation on twitter my understanding is that one should get the vtimezone from the underlying data

i may be able to create a POC of that by the weekend

bancsorin10 · 2021-10-29T10:46:38Z

Greetings, as of my understanding the warnings are from pytz newest version. Is it worth it to make a smaller PR to fix the pytz version in the setup.py to a version that is working so the build is not broken(I think this warning introduced other unexpected behaviours - e.g. fresh clone and build - trying to create events - cannot change the hours range). For me it is not clear the state of this PR if there is anything I can help out with lmk I wish to contribute and accelerate this PR.

pjkaufman · 2021-10-29T14:57:00Z

That may work, but the change happened as of python 3.9, so I think we would have to discontinue the use of python 3.9 in order for that to work, but I am aomewhat new to python. I still have some changes I have not committed because they are not ready yet, but I can see about adding to it this weekend

…

On Fri, Oct 29, 2021, 6:46 AM Turt7le ***@***.***> wrote: Greetings, as of my understanding the warnings are from pytz newest version. Is it worth it to make a smaller PR to fix the pytz version in the setup.py to a version that is working so the build is not broken(I think this warning introduced other unexpected behaviours - e.g. fresh clone and build - trying to create events - cannot change the hours range). For me it is not clear the state of this PR if there is anything I can help out with lmk I wish to contribute and accelerate this PR. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1093 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHEDPO4MPST4CMISDL7NHSLUJKCSTANCNFSM5GQNTTHA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

WhyNotHugo · 2021-11-02T21:45:06Z

@bancsorin10 Agreed. A separate PR pinning a working version of pytz is welcome, at least until we have a definitive version of PEP495 support.

pjkaufman · 2021-11-03T02:27:35Z

I made some changes to remove a lot of the pytz method calls and it seems to work for some things. The unit tests are failing (41 of them to be exact) and some of that is because I have not implemented logic for DST dates prior to 2007, I have no logic in place for BST dates, and the TZID is being listed at the timezone name instead of the ZoneInfo key.

However, I tried to commit my changes, but I got several errors from the precommit checks. They currently are preventing me from actually commiting to my own repo, so I will just list out some of the errors and ask for ideas on how to fix them.

The first issue it is really complaining about is the following:

try:
    from zoneinfo import ZoneInfo
except ImportError:
    from backports import zoneinfo as ZoneInfo

The precheck says the following about it:

khal/utils.py:29: error: Incompatible import of "ZoneInfo" (imported name has type Module, local name has type "Type[ZoneInfo]")
tests/utils.py:7: error: Incompatible import of "ZoneInfo" (imported name has type Module, local name has type "Type[ZoneInfo]")

Any ideas on how to fix this?

pjkaufman · 2021-11-03T02:46:30Z

I figured out how to get past the the precommit check failures for flake8, but I am not sure what I need to do to fix the actual errors. Please let me know what I should do to fix them. I am also unaware of what we should do to correctly replace transition time checking and BST time checking. Any ideas are welcome.

pjkaufman · 2021-11-03T02:47:20Z

khal/icalendar.py

+try:
+    from zoneinfo import ZoneInfo
+except ImportError:
+    from backports import zoneinfo as ZoneInfo


For some reason flake8 does not like this. Any ideas on how to fix it?

is this problem still up? Is there a full log of the error. I will look into it and come back

pjkaufman · 2021-11-03T02:48:46Z

khal/khalendar/event.py

+def _get_transition_dates_dst_for_daterange(tz, start_date, end_date):
+    # TODO: add date range based algorithms for determining the correct dst
+    # time zones where rules exist pjk
+    if start_date.year < 2007:
+        msg = (
+            "Cannot work with start dates prior to 2007 at this time. Date supplied was" +
+            str(start_date) + ".")
+        logger.fatal(msg)
+        raise FatalError(  # because in ikhal you won't see the logger's output
+            msg
+        )
+
+    year = start_date.year - 1
+    years = []
+    while year <= end_date.year + 1:
+        years.append(year)
+        year += 1
+
+    index_of_first_transition_before_start_date = 0
+    index = 0
+    transition_times = []
+    for year in years:
+        marchCal = calendar.monthcalendar(year, 3)
+        first_week = marchCal[0]
+        second_week = marchCal[1]
+        third_week = marchCal[2]
+
+        if first_week[calendar.SUNDAY]:
+            dst_begins = second_week[calendar.SUNDAY]
+        else:
+            dst_begins = third_week[calendar.SUNDAY]
+
+        dst_start = dt.datetime(year, 3, dst_begins, 2, tzinfo=tz)
+        transition_times.append(dst_start)
+        if dst_start < start_date:
+            index_of_first_transition_before_start_date = index
+
+        if end_date < dst_start:
+            break
+
+        novemberCal = calendar.monthcalendar(year, 11)
+        first_week = novemberCal[0]
+        second_week = novemberCal[1]
+
+        if first_week[calendar.SUNDAY]:
+            dst_ends = first_week[calendar.SUNDAY]
+        else:
+            dst_ends = second_week[calendar.SUNDAY]
+
+        dst_end = dt.datetime(year, 11, dst_ends, 2, tzinfo=tz)
+        transition_times.append(dst_end)
+        if end_date < dst_end:
+            break
+
+        index += 1
+
+    return transition_times[index_of_first_transition_before_start_date:]


Here is an idea for how to get transition dates without pytz.

pjkaufman · 2021-11-03T02:51:09Z

khal/khalendar/event.py

-            tz.fromutc(tz._utc_transition_times[num]).replace(tzinfo=None))
-        subcomp.add('TZOFFSETTO', tz._transition_info[num][0])
-        subcomp.add('TZOFFSETFROM', tz._transition_info[num - 1][0])
+            tz.fromutc(transition_times[index]).replace(tzinfo=None)


For some reason the TZID is being listed as the timezone name (i.e. EDT, CET, etc.) instead of the passed in name for the ZoneInfo (i.e. "UTC", "America/New_York", etc.).

pjkaufman · 2021-11-03T02:52:30Z

khal/settings/utils.py

+try:
+    import zoneinfo as ZoneInfo
+except ImportError:  # I am not sure if this is correct for the backport
+    from backports import zoneinfo as ZoneInfo


I am not sure if this is correct for the backport as I did not change it while I imported the module instead of a module inside zoneinfo for the try portion of the try except.

RonnyPfannschmidt · 2021-11-03T06:18:39Z

khal/controllers.py

+try:
+    import zoneinfo as ZoneInfo
+except ImportError:  # I am not sure if this is correct for the backport
+    from backports import zoneinfo as ZoneInfo


Suggested change

from backports import zoneinfo as ZoneInfo

from backports.zoneinfo import ZoneInfo

I did what it says to do in the documentation I could find: https://pypi.org/project/backports.zoneinfo/

For some reason

from backports.zoneinfo import ZoneInfo

Yields the following warning: Import "backports.zoneinfo" could not be resolved

When flake8 runs on Python3.9, this library won't be installed. It's safe to ignore this specific error.

bancsorin10 · 2021-11-03T09:31:39Z

@bancsorin10 Agreed. A separate PR pinning a working version of pytz is welcome, at least until we have a definitive version of PEP495 support.

from my testing I could not pinpoint the problem. I used python 3.9 with pytz version as old as 2013, and python 3.7.7 with the newest versions of pytz. It might be a combination of both or my system may just be too corrupted even tho I made the builds with a virtual python environment. I will try a few more versions and if I find something before this pr goes live I'll let you know.

Terrance · 2021-11-03T09:33:17Z

@bancsorin10 The issue is likely with tzlocal rather than pytz directly, see my PR linked above.

pjkaufman · 2021-11-03T11:36:51Z

I have been able to determine that the TZID issue is probably an icalendar issue where it is not handling ZoneInfo and date util timezone names correctly: collective/icalendar#291

I have suggested a change and can make a PR and see what happens, but I am not sure what to do if the issue is in icalendar and they do not choose to fix it.

…d BDT and DST value determination for all reasonable dates

…nfo value

pjkaufman · 2022-05-08T22:25:55Z

Regarding creating the VTIMEZONEs:
we can probably create something similar as before from ZoneInfo._ttinfos, Zoneinfo._trans_utc and Zoneinfo._fixed_offsets. But we could use the chance to read the timezone information values and extract the rrules from those (would lead to smaller VTIMEZONEs).

That is quite interesting. I was unaware that this was a thing. I can see about adding it if you would like.

Yes, please go ahead.

Could you please link out to the documentation for ZoneInfo._ttinfos, Zoneinfo._trans_utc and Zoneinfo._fixed_offsets as I cannot seem to find it? Without the documentation and the fact that python 3.9.7 keeps saying that

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.9/zoneinfo/__init__.py", line 27, in __getattr__
    raise AttributeError(f"module {__name__!r} has no attribute {name!r}")
AttributeError: module 'zoneinfo' has no attribute '_ttinfos'

It may be that I am just misunderstanding what you mean here size it it unclear whether it is the zone info instance or the module that has the data on it. Thanks for the help!

geier · 2022-05-09T07:47:37Z

I don't think there is any documentation for those _ variables apart from the source code

geier · 2022-05-09T07:51:38Z

But I now see that there is also a C implementation of the module (which probably gets loaded for you). I don't think we can access those transition times if the C implementation gets used, but I'd need to have a look into this.

geier · 2022-05-09T08:12:07Z

It looks like if we import ZoneInfo like this

In [1]: from zoneinfo._zoneinfo import ZoneInfo
In [2]: berlin = ZoneInfo('Europe/Berlin')
In [3]: berlin._trans_local

we can force to import the python version.

Also, we would need to first upgrade collectivie/icalendar to use tzinfo to completely switch to tzinfo.

But the current vtimezone implementation definitively is a mess and needs an upgrade.

Perhaps it's more valuable, to have a look at how the ZoneInfo implementation loads the timezone, but I'm not sure what the best way forward here is at the moment.

pjkaufman · 2022-05-31T01:02:40Z

I plan to make a couple of changes yet on the master branch of my fork, but I would like to ask that someone that uses this app takeover the changes from there since I no longer use this app which means that I don't have a good way to verify that it is working correctly beyond the UTs which may not be extensive enough to be considered proof that the app is working, besides the fact that my changes modify them as well.

I would also recommend updating icalendar to allow for use without pytz as that was a major blocker that has drawn out the updating of this repo.

Beyond that, I plan to see about swapping out the logic for timezone info and finishing the rebase of the branch before stopping making changes to my fork.

I do hope that this change gets implemented as it seems necessary. I also hope that the code that has been added here will aid in the transition from pytz.

Please let me know if there would be a problem with me finishing the rebase and making the timezone transition times change before closing out the PR to allow another dev to hopefully take over.

… which removed warnings and added myself to the authors list as per the contributing instructions

for more information, see https://pre-commit.ci

…d BDT and DST value determination for all reasonable dates

…nfo value

for more information, see https://pre-commit.ci

…y anything

…c which supposedly will work based on comments on the PR

for more information, see https://pre-commit.ci

…ome of the pre commit complaints

for more information, see https://pre-commit.ci

pjkaufman · 2022-06-01T23:23:46Z

@WhyNotHugo , @geier , I have made several of the changes requested, but I am not able to build it locally and do not have the expertise to figure out the python errors. However since I plan to relinquish the remaining work and allow someone that is familiar with python and is using khal to complete this PR, I do not see resolving the local build problems due to bad dependency installations as an issue.

Hopefully this will PR can serve as a base for making the change over to no longer use pytz. I hope that the dependencies get updated soon to be compliant with no longer using pytz to help this project keep moving forward. Thank you for letting me try my hand at creating this fix.

WhyNotHugo reviewed Oct 23, 2021

View reviewed changes

khal/khalendar/event.py Show resolved Hide resolved

khal/khalendar/khalendar.py Outdated Show resolved Hide resolved

pjkaufman marked this pull request as draft October 23, 2021 12:30

pjkaufman changed the title ~~Update Timezone Code to Fix Warnings Printed When Runing khal~~ Update khal to Follow PEP495 Removing Deprecation Warnings Oct 23, 2021

nim65s reviewed Oct 24, 2021

View reviewed changes

setup.py Outdated Show resolved Hide resolved

RonnyPfannschmidt mentioned this pull request Oct 26, 2021

pytz shim tzinfo exceptions on serializing events when creating #1096

Closed

pjkaufman commented Nov 3, 2021

View reviewed changes

RonnyPfannschmidt reviewed Nov 3, 2021

View reviewed changes

Terrance mentioned this pull request Nov 3, 2021

Pin to tzlocal 2.x to (temporarily) avoid zoneinfo upgrade #1098

Merged

pjkaufman requested a review from WhyNotHugo November 3, 2021 11:38

pjkaufman added 4 commits May 8, 2022 17:41

updated setup requirements

78d8121

fix setup dependency

3f418f3

preliminary setup for the changes which still needs TZID value fix an…

7ed5d7a

…d BDT and DST value determination for all reasonable dates

fixed an issue with incorrectly using a module to initialize a zone i…

c5bcc14

…nfo value

pjkaufman and others added 7 commits June 1, 2022 17:57

Changed locale to use the method suggested by the deprecation warning…

c934868

… which removed warnings and added myself to the authors list as per the contributing instructions

[pre-commit.ci] auto fixes from pre-commit.com hooks

1fc2a33

for more information, see https://pre-commit.ci

updated setup requirements

30d913a

fix setup dependency

e1b7732

preliminary setup for the changes which still needs TZID value fix an…

fa43f9b

…d BDT and DST value determination for all reasonable dates

fixed an issue with incorrectly using a module to initialize a zone i…

76a2e1f

…nfo value

adding rebased info to fix merge conflicts

775218c

pjkaufman force-pushed the master branch from 969d27e to 775218c Compare June 1, 2022 22:09

pre-commit-ci bot and others added 10 commits June 1, 2022 22:09

[pre-commit.ci] auto fixes from pre-commit.com hooks

a0dc1c7

for more information, see https://pre-commit.ci

updated the way we get the transition times, but have no way to verif…

d9db0bb

…y anything

some import cleanup and a revert of logic to get back to the old logi…

e7221c9

…c which supposedly will work based on comments on the PR

add pytz to hopefully get rid of code complaint

a800bb7

[pre-commit.ci] auto fixes from pre-commit.com hooks

51b3f5b

for more information, see https://pre-commit.ci

updated imports as per comments on the PR and it will hopefully fix s…

22b6df6

…ome of the pre commit complaints

updated imports as per comments on the PR and it will hopefully fix s…

87bf616

…ome of the pre commit complaints

[pre-commit.ci] auto fixes from pre-commit.com hooks

2bfa4e6

for more information, see https://pre-commit.ci

updated imports as per precommit and fixed a line length issue

79f69d8

udoing a line length issue fix due to indentation error

8590bcb

geier added upstream type: 3rd party compatibility labels Jun 25, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update khal to Follow PEP495 Removing Deprecation Warnings #1093

Update khal to Follow PEP495 Removing Deprecation Warnings #1093

pjkaufman commented Oct 22, 2021 •

edited

Loading

pjkaufman commented Oct 22, 2021

pjkaufman commented Oct 22, 2021

pjkaufman commented Oct 22, 2021

pjkaufman commented Oct 23, 2021

pjkaufman commented Oct 23, 2021

WhyNotHugo commented Oct 23, 2021 via email

WhyNotHugo commented Oct 23, 2021 via email

pjkaufman commented Oct 23, 2021 •

edited

Loading

pjkaufman commented Oct 25, 2021

RonnyPfannschmidt commented Oct 28, 2021

bancsorin10 commented Oct 29, 2021

pjkaufman commented Oct 29, 2021 via email

WhyNotHugo commented Nov 2, 2021

pjkaufman commented Nov 3, 2021

pjkaufman commented Nov 3, 2021

pjkaufman Nov 3, 2021

bancsorin10 Nov 3, 2021

pjkaufman Nov 3, 2021

pjkaufman Nov 3, 2021

pjkaufman Nov 3, 2021

RonnyPfannschmidt Nov 3, 2021

pjkaufman Nov 3, 2021

WhyNotHugo Nov 3, 2021

bancsorin10 commented Nov 3, 2021

Terrance commented Nov 3, 2021

pjkaufman commented Nov 3, 2021 •

edited

Loading

pjkaufman commented May 8, 2022 •

edited

Loading

geier commented May 9, 2022

geier commented May 9, 2022

geier commented May 9, 2022 •

edited

Loading

pjkaufman commented May 31, 2022

pjkaufman commented Jun 1, 2022

	from backports import zoneinfo as ZoneInfo
	from backports.zoneinfo import ZoneInfo

Update khal to Follow PEP495 Removing Deprecation Warnings #1093

Are you sure you want to change the base?

Update khal to Follow PEP495 Removing Deprecation Warnings #1093

Conversation

pjkaufman commented Oct 22, 2021 • edited Loading

pjkaufman commented Oct 22, 2021

pjkaufman commented Oct 22, 2021

pjkaufman commented Oct 22, 2021

pjkaufman commented Oct 23, 2021

pjkaufman commented Oct 23, 2021

WhyNotHugo commented Oct 23, 2021 via email

WhyNotHugo commented Oct 23, 2021 via email

pjkaufman commented Oct 23, 2021 • edited Loading

pjkaufman commented Oct 25, 2021

RonnyPfannschmidt commented Oct 28, 2021

bancsorin10 commented Oct 29, 2021

pjkaufman commented Oct 29, 2021 via email

WhyNotHugo commented Nov 2, 2021

pjkaufman commented Nov 3, 2021

pjkaufman commented Nov 3, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bancsorin10 commented Nov 3, 2021

Terrance commented Nov 3, 2021

pjkaufman commented Nov 3, 2021 • edited Loading

pjkaufman commented May 8, 2022 • edited Loading

geier commented May 9, 2022

geier commented May 9, 2022

geier commented May 9, 2022 • edited Loading

pjkaufman commented May 31, 2022

pjkaufman commented Jun 1, 2022

pjkaufman commented Oct 22, 2021 •

edited

Loading

pjkaufman commented Oct 23, 2021 •

edited

Loading

pjkaufman commented Nov 3, 2021 •

edited

Loading

pjkaufman commented May 8, 2022 •

edited

Loading

geier commented May 9, 2022 •

edited

Loading