OBS-1831 Fix unparseable date: "01/01/2025 " exception during stock movements#5068
OBS-1831 Fix unparseable date: "01/01/2025 " exception during stock movements#5068
Conversation
github-actions
bot
added
type: bug
| } | ||
|
|
||
| private Date parseDateShipped(String date) { | ||
| return DateUtil.asDate(date, Constants.DELIVERY_DATE_FORMATTER) |
There was a problem hiding this comment.
this is the real change. Notice that before we were providing the specific formatter to use but now we don't. Now this will use the flexible date formatter which allows for a much wider range of possible inputs
| /** | ||
| * DateTimeFormatter used to parse a String to a datetime class, such as java.time.Instant. | ||
| */ | ||
| static final DateTimeFormatter FLEXIBLE_DATE_TIME_ZONE_FORMAT = new DateTimeFormatterBuilder() |
There was a problem hiding this comment.
not new code. Just moved from InstantValueConverter so that it can be shared
| "01/01/00 00:00 Z" || "0001-01-01T00:00:00Z" | "No time or timezone our format two digit year" | ||
| // When not given a time or timezone, we default to midnight UTC. | ||
| "01/01/2000" || "2000-01-01T00:00:00Z" | "No time or timezone our format" | ||
| "2000-01-01" || "2000-01-01T00:00:00Z" | "No time or timezone ISO format" |
There was a problem hiding this comment.
we can parse to a Date without providing a timezone and it automatically uses UTC now. Yay!
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #5068 +/- ##
=========================================
Coverage 7.97% 7.97%
- Complexity 907 912 +5
=========================================
Files 632 632
Lines 42983 42960 -23
Branches 10406 10404 -2
=========================================
Hits 3427 3427
+ Misses 39035 39011 -24
- Partials 521 522 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| # ahead of UTC, this can cause the date to actually become the next day. It can also cause | ||
| # inconsistencies across hosts/environments if they're configured for different local timezones. | ||
| # Avoid using this format going forward! Only kept to maintain backwards compatability. | ||
| - 'MM/dd/yyyy' |
There was a problem hiding this comment.
this problem will always be present so long as we use the Date class. Explicility calling
Date date = DateUtil.asDate("01/01/2000")
will correctly default to UTC, but if we rely on Grails' databinding (ie have a controller method take in a Command object arg that has a Date field), Strings like "01/01/2000" will default to the local server time. This is why switching to Instant and LocalDate for new features is better
ewaterman
changed the title
3 participants
✨ Description of Change
Link to GitHub issue or Jira ticket:
Description: This change switches the parsing of dateShipped and dateRequested fields during stock movements to use the new DateUtil.asDate method (with no SimpleDateFormat provided so that it uses the flexible format).
I also modified how the method works so that it uses the same DateTimeFormatter that we use when parsing a String to an Instant. That way it gets around the issue with parsing "MM/dd/yyyy" and defaulting to the local timezone (now it always uses UTC).
📷 Screenshots & Recordings (optional)