[LCHIB-612] Add a workaround for handling timezone abbreviations in d…

[ono-max]

…ateutil

The dateutil package does not support timezone abbreviations like "PDT" by default.

We can reproduce the warning in the following script:

from dateutil import parser

date_str = "2024-04-01 10:00:00 PDT"
parsed = parser.parse(date_str)
print(parsed)

$ python foo.py 
/Users/ono-max/.local/share/virtualenvs/cli-tPknK2Me/lib/python3.12/site-packages/dateutil/parser/_parser.py:1207: UnknownTimezoneWarning: tzname PDT identified but not understood.  Pass `tzinfos` argument in order to correctly return a timezone-aware datetime.  In a future version, this will raise an exception.
  warnings.warn("tzname {tzname} identified but not understood.  "
2024-04-01 10:00:00

As a workaround, we need to pass the map to tzinfos parameter.

See: dateutil/dateutil#932

from dateutil import parser
from dateutil.tz import gettz

COMMON_TIMEZONES = {
    "UTC": gettz("UTC"),
    # https://time.now/timezones/pdt/
    "PDT": gettz("America/Los_Angeles"),
    # https://time.now/timezones/jst/
    "JST": gettz("Asia/Tokyo"),
}

date_str = "2024-04-01 10:00:00 PDT"
parsed = parser.parse(date_str, tzinfos=COMMON_TIMEZONES)
print(parsed)

$ python foo.py
2024-04-01 10:00:00-07:00

[Konboi]

I understand the cause of problem.
Can you write a test to confirm that this change suppresses the warning message?
If we set a time zone that isn't registered, a warning message should appear. On the other hand, if we set a registered time zone (e.g. JST), not warning should be shown.

[ono-max]

@Konboi

I added new tests: 842f235.

Can you please review this PR, again?

[Copilot]

Pull Request Overview

This pull request addresses the issue with handling timezone abbreviations by mapping them via the tzinfos parameter in dateutil.parser.parse. Key changes include:

• Adding tests for timestamps with both known and unknown timezone abbreviations.
• Introducing a utility module (COMMON_TIMEZONES) to map common abbreviations.
• Modifying the case_event timestamp parsing to use the COMMON_TIMEZONES mapping.

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
tests/commands/record/test_case_event.py	Adds tests to verify proper handling of known and unknown timezone abbreviations.
launchable/utils/common_tz.py	Introduces a mapping for common timezone abbreviations using dateutil.tz.gettz.
launchable/commands/record/case_event.py	Updates timestamp parsing to use the tzinfos parameter with the COMMON_TIMEZONES map.

Comments suppressed due to low confidence (1)

launchable/commands/record/case_event.py:162

• Consider adding a brief comment explaining the use of the 'timestr' and 'tzinfos' keyword parameters to clarify that this change is to support proper parsing of timezone abbreviations as per the updated dateutil behavior.

                date = dateutil.parser.parse(timestr=ts, tzinfos=COMMON_TIMEZONES)

[Konboi]

LGTM

---

But I left a question as comment

[Konboi]

Just a question: Why did you use assertTrue and assertIn instead of assertEqual(result["createdAt"], "2024-06-23T12:34:56.789 -7:00")?

[ono-max]

I just feel like it's clearer to test them separately. The first line, assertTrue guarantees whether the time isn't changed. The second line, assertIn guarantees that the timezone is parsed correctly.

But, I don't have a strong opinion, so I'm gonna change that so that it uses assertEqual(result["createdAt"], "2024-06-23T12:34:56.789 -7:00")

[ono-max]

bc99065

[Konboi]

ditto

[ono-max]

This is because dateutil.parser uses the default timezone if the timezone is not supported. In my local env, it's something like this: 2024-06-23T12:34:56.789000+09:00

[ono-max]

7fc8428

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud