Skip to content

fix: preserve location in RetryAmbiguousDateWithSwap retry#169

Open
Yanhu007 wants to merge 1 commit intoaraddon:masterfrom
Yanhu007:fix/retry-swap-timezone
Open

fix: preserve location in RetryAmbiguousDateWithSwap retry#169
Yanhu007 wants to merge 1 commit intoaraddon:masterfrom
Yanhu007:fix/retry-swap-timezone

Conversation

@Yanhu007
Copy link
Copy Markdown

Fixes #161

Problem

When RetryAmbiguousDateWithSwap retries parsing after a "month out of range" error, it calls parseTime with time.Local instead of the original loc parameter. This causes timezone inconsistency:

// Uses time.Local in retry → returns CEST
t0, _ := dateparse.ParseAny("21/09/2010", dateparse.RetryAmbiguousDateWithSwap(true))
// → 2010-09-21 00:00:00 +0200 CEST

// No retry needed → returns UTC
t1, _ := dateparse.ParseAny("09/21/2010", dateparse.RetryAmbiguousDateWithSwap(true))
// → 2010-09-21 00:00:00 +0000 UTC

// t0 != t1, but they represent the same date!

Fix

One-line change: pass loc (the original location parameter) instead of time.Local to the retry parseTime call.

All existing tests pass.

When RetryAmbiguousDateWithSwap retries parsing after a "month out
of range" error, it called parseTime with time.Local instead of the
original location parameter. This causes inconsistent timezones:

  ParseAny("21/09/2010", RetryAmbiguousDateWithSwap(true))
  → 2010-09-21 00:00:00 +0200 CEST  (uses time.Local in retry)

  ParseAny("09/21/2010", RetryAmbiguousDateWithSwap(true))
  → 2010-09-21 00:00:00 +0000 UTC   (no retry needed)

Fix: pass the original loc parameter to the retry parseTime call
instead of time.Local, ensuring consistent timezone handling.

Fixes araddon#161
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Different timezone used with dateparse.RetryAmbiguousDateWithSwap(true) option.

1 participant