[CUS-8390] Added 2 NLP's one will generate time in given format and the other one will add time. #253
Conversation
…he other one will add time.
WalkthroughThis pull request introduces comprehensive date/time utilities for the Testsigma testing framework. It adds a core TimeUtil class with automatic format detection and parsing/formatting capabilities, along with four new classes: two data generators and two web actions for manipulating and storing UTC times. Changes
Sequence Diagram(s)sequenceDiagram
actor User
participant AddTimeAction as AddTimeToGivenTime<br/>(Web Action)
participant TimeUtil
participant Runtime as Runtime<br/>Variables
User->>AddTimeAction: execute(inputTime, amount, unit, outputFormat)
AddTimeAction->>TimeUtil: detectInputFormat(inputTime)
TimeUtil-->>AddTimeAction: DetectedFormat (type, formatter)
AddTimeAction->>TimeUtil: getFormatType(outputFormat)
TimeUtil-->>AddTimeAction: FormatType
AddTimeAction->>TimeUtil: validateConversion(inputType, outputType)
TimeUtil-->>AddTimeAction: OK or IllegalArgumentException
AddTimeAction->>TimeUtil: parseTime(inputTime)
TimeUtil-->>AddTimeAction: LocalDateTime
Note over AddTimeAction: Add duration<br/>(amount + unit)
AddTimeAction->>TimeUtil: formatTime(resultTime, outputFormat)
TimeUtil-->>AddTimeAction: formatted string
AddTimeAction->>Runtime: Store result in variable
Runtime-->>AddTimeAction: Success
AddTimeAction-->>User: Result with message
sequenceDiagram
actor User
participant StoreUTCAction as StoreCurrentUTCTime<br/>(Web Action)
participant TimeUtil
participant Runtime as Runtime<br/>Variables
User->>StoreUTCAction: execute(timeFormat, runtimeVariable)
StoreUTCAction->>TimeUtil: Get current UTC time
TimeUtil-->>StoreUTCAction: ZonedDateTime (UTC)
StoreUTCAction->>TimeUtil: formatTime(utcTime, timeFormat)
TimeUtil-->>StoreUTCAction: formatted string
StoreUTCAction->>Runtime: Store formatted time in variable
Runtime-->>StoreUTCAction: Success
StoreUTCAction-->>User: Result with success message
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (7)
date_time_utilities/src/main/java/com/testsigma/addons/util/TimeUtil.java (2)
130-139: Improve error messages to be more user-friendly.The validation error messages are too generic and don't clearly explain the constraint to users.
Apply this diff to improve error messages:
public static void validateConversion(FormatType inputType, FormatType outputType) throws IllegalArgumentException { // Time-only to date-only is not allowed if (inputType == FormatType.TIME_ONLY && outputType == FormatType.DATE_ONLY) { - throw new IllegalArgumentException("can't convert to this format"); + throw new IllegalArgumentException("Cannot convert time-only format to date-only format. Please use a datetime output format instead."); } // Date-only to time-only is not allowed if (inputType == FormatType.DATE_ONLY && outputType == FormatType.TIME_ONLY) { - throw new IllegalArgumentException("can't convert to this format"); + throw new IllegalArgumentException("Cannot convert date-only format to time-only format. Please use a datetime output format instead."); } }
169-270: Refactor the large switch statement to reduce duplication.The switch statement spans over 100 lines with highly repetitive code. Each case follows the same pattern: create formatter, format time, return result. This violates the DRY principle and makes the code harder to maintain.
Consider refactoring to use a Map-based approach:
private static final Map<String, String> FORMAT_PATTERNS = new HashMap<>(); static { // Time-only formats FORMAT_PATTERNS.put("HH:MM", "HH:mm"); FORMAT_PATTERNS.put("HH:MM:SS", "HH:mm:ss"); FORMAT_PATTERNS.put("hh:mm AM/PM", "hh:mm a"); FORMAT_PATTERNS.put("hh:mm:ss AM/PM", "hh:mm:ss a"); // Date-only formats FORMAT_PATTERNS.put("YYYY-MM-DD", "yyyy-MM-dd"); FORMAT_PATTERNS.put("DD-MM-YYYY", "dd-MM-yyyy"); FORMAT_PATTERNS.put("MM/DD/YYYY", "MM/dd/yyyy"); FORMAT_PATTERNS.put("DD/MM/YYYY", "dd/MM/yyyy"); // Datetime formats FORMAT_PATTERNS.put("YYYY-MM-DD HH:MM", "yyyy-MM-dd HH:mm"); FORMAT_PATTERNS.put("YYYY-MM-DD HH:MM:SS", "yyyy-MM-dd HH:mm:ss"); // ... add remaining formats FORMAT_PATTERNS.put("YYYY-MM-DDTHH:MM:SS", "yyyy-MM-dd'T'HH:mm:ss"); FORMAT_PATTERNS.put("YYYY-MM-DDTHH:MM:SSZ", "yyyy-MM-dd'T'HH:mm:ss'Z'"); } public static String formatTime(LocalDateTime localTime, String format) throws IllegalArgumentException { if (localTime == null) { throw new IllegalArgumentException("LocalDateTime cannot be null"); } String pattern = FORMAT_PATTERNS.get(format); if (pattern == null) { throw new IllegalArgumentException("Invalid time format: " + format); } DateTimeFormatter formatter = DateTimeFormatter.ofPattern(pattern); return localTime.format(formatter); }This approach is more maintainable and makes it easier to add new formats.
date_time_utilities/src/main/java/com/testsigma/addons/web/StoreCurrentUTCTime.java (1)
37-57: Consider adding null checks for defensive programming.While the Testsigma SDK may guarantee that
getValue()doesn't return null, adding explicit null checks would make the code more defensive and provide clearer error messages if assumptions change.Consider adding validation at the start of the method:
public com.testsigma.sdk.Result execute() { try { + if (timeFormat == null || timeFormat.getValue() == null) { + throw new IllegalArgumentException("time-format parameter is required"); + } + if (runtimeVariable == null || runtimeVariable.getValue() == null) { + throw new IllegalArgumentException("runtime-variable parameter is required"); + } + // Get the current UTC time java.time.ZonedDateTime utcTime = java.time.ZonedDateTime.now(java.time.ZoneOffset.UTC);date_time_utilities/src/main/java/com/testsigma/addons/DataGenerators/StoreCurrentUTCTime.java (1)
21-39: Consider adding null checks for defensive programming.Similar to the web action version, adding explicit null validation would improve robustness.
Consider adding validation:
public TestData generate() throws Exception { try { + if (timeFormat == null || timeFormat.getValue() == null) { + throw new IllegalArgumentException("time-format parameter is required"); + } + // Get the current UTC time java.time.ZonedDateTime utcTime = java.time.ZonedDateTime.now(java.time.ZoneOffset.UTC);date_time_utilities/src/main/java/com/testsigma/addons/web/AddTimeToGivenTime.java (2)
47-65: Add specific handling for NumberFormatException.Line 50 calls
Long.parseLong()which can throwNumberFormatExceptionif the user provides invalid input. Currently this would be caught by the genericExceptionhandler (line 112), but providing a specific error message would improve user experience.Consider adding a specific catch block:
} catch (IllegalArgumentException e) { // Handle conversion errors specifically String errorMessage = e.getMessage(); logger.warn(errorMessage); setErrorMessage(errorMessage); return com.testsigma.sdk.Result.FAILED; + } catch (NumberFormatException e) { + String errorMessage = "Invalid time-amount: must be a valid number"; + logger.warn(errorMessage); + setErrorMessage(errorMessage); + return com.testsigma.sdk.Result.FAILED; } catch (Exception e) {
68-92: Consider simplifying the time unit switch statement.The switch statement is readable but could be more maintainable using a functional approach. This is an optional improvement.
Consider using a map-based approach:
private static final Map<String, BiFunction<LocalDateTime, Long, LocalDateTime>> TIME_OPERATIONS = new HashMap<>(); static { TIME_OPERATIONS.put("SECONDS", LocalDateTime::plusSeconds); TIME_OPERATIONS.put("MINUTES", LocalDateTime::plusMinutes); TIME_OPERATIONS.put("HOURS", LocalDateTime::plusHours); TIME_OPERATIONS.put("DAYS", LocalDateTime::plusDays); TIME_OPERATIONS.put("WEEKS", LocalDateTime::plusWeeks); TIME_OPERATIONS.put("MONTHS", LocalDateTime::plusMonths); TIME_OPERATIONS.put("YEARS", LocalDateTime::plusYears); } // In execute(): BiFunction<LocalDateTime, Long, LocalDateTime> operation = TIME_OPERATIONS.get(unitStr); if (operation == null) { throw new IllegalArgumentException("Invalid time unit: " + unitStr); } LocalDateTime resultTime = operation.apply(inputTime, amount);This approach makes it easier to maintain and test.
date_time_utilities/src/main/java/com/testsigma/addons/DataGenerators/AddTimeToGivenTime.java (1)
29-93: Add specific handling for NumberFormatException.Similar to the web action, line 32 calls
Long.parseLong()which can throwNumberFormatException. Providing a specific error message would improve the user experience.Consider adding a specific catch block:
} catch (IllegalArgumentException e) { // Handle conversion errors specifically String errorMessage = e.getMessage(); logger.warn(errorMessage); throw new Exception("Failed to add time to given time: " + errorMessage); + } catch (NumberFormatException e) { + String errorMessage = "Invalid time-amount: must be a valid number"; + logger.warn(errorMessage); + throw new Exception("Failed to add time to given time: " + errorMessage); } catch (Exception e) {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
date_time_utilities/src/main/java/com/testsigma/addons/DataGenerators/AddTimeToGivenTime.java(1 hunks)date_time_utilities/src/main/java/com/testsigma/addons/DataGenerators/StoreCurrentUTCTime.java(1 hunks)date_time_utilities/src/main/java/com/testsigma/addons/util/TimeUtil.java(1 hunks)date_time_utilities/src/main/java/com/testsigma/addons/web/AddTimeToGivenTime.java(1 hunks)date_time_utilities/src/main/java/com/testsigma/addons/web/StoreCurrentUTCTime.java(1 hunks)
🔇 Additional comments (3)
date_time_utilities/src/main/java/com/testsigma/addons/web/StoreCurrentUTCTime.java (1)
22-34: Good design: Proper format support for UTC and ISO_8601.The allowed values include "UTC" and "ISO_8601" formats, and the implementation correctly uses
ZonedDateTime(line 40) with theformatTime(ZonedDateTime, String)overload (line 43), which properly supports these formats. This is the right approach for handling UTC time.date_time_utilities/src/main/java/com/testsigma/addons/web/AddTimeToGivenTime.java (1)
26-37: Correct format restrictions for AddTimeToGivenTime.The
timeFormatallowedValues appropriately excludes "UTC" and "ISO_8601" formats. UnlikeStoreCurrentUTCTimewhich works withZonedDateTime, this action usesLocalDateTime(line 64) for time arithmetic, so those formats wouldn't be appropriate here.date_time_utilities/src/main/java/com/testsigma/addons/util/TimeUtil.java (1)
305-308: Clarify the purpose or remove the legacy formatTime method.The comment indicates this method is for backward compatibility, but the implementation seems problematic. It attempts to parse the input string directly as a
LocalDateTimewithout format detection, which will fail for most real-world time strings (like "14:30" or "2025-11-06").Please verify:
- Is this method actually used anywhere in the codebase?
- What is the expected input format for this method?
- If it's truly legacy and unused, consider removing it to reduce confusion.
Run this script to check for usages:
| @TestDataFunctionParameter(reference = "test-data") | ||
| private com.testsigma.sdk.TestDataParameter testData; | ||
| @TestDataFunctionParameter(reference = "time-amount") | ||
| private com.testsigma.sdk.TestDataParameter timeAmount; | ||
| @TestDataFunctionParameter(reference = "time-unit") | ||
| private com.testsigma.sdk.TestDataParameter timeUnit; | ||
| @TestDataFunctionParameter(reference = "time-format") | ||
| private com.testsigma.sdk.TestDataParameter timeFormat; |
There was a problem hiding this comment.
Add allowedValues annotations to guide users.
Unlike the web action version, the data generator doesn't specify allowedValues for time-unit and time-format parameters. Users need to see what options are available.
Apply this diff to add allowedValues:
@TestDataFunctionParameter(reference = "test-data")
private com.testsigma.sdk.TestDataParameter testData;
@TestDataFunctionParameter(reference = "time-amount")
private com.testsigma.sdk.TestDataParameter timeAmount;
-@TestDataFunctionParameter(reference = "time-unit")
+@TestDataFunctionParameter(reference = "time-unit", allowedValues = {"SECONDS", "MINUTES", "HOURS", "DAYS", "WEEKS", "MONTHS", "YEARS"})
private com.testsigma.sdk.TestDataParameter timeUnit;
-@TestDataFunctionParameter(reference = "time-format")
+@TestDataFunctionParameter(reference = "time-format", allowedValues = {
+ "HH:MM", "HH:MM:SS",
+ "YYYY-MM-DD", "DD-MM-YYYY", "MM/DD/YYYY", "DD/MM/YYYY",
+ "YYYY-MM-DD HH:MM", "YYYY-MM-DD HH:MM:SS",
+ "DD-MM-YYYY HH:MM", "DD-MM-YYYY HH:MM:SS",
+ "MM/DD/YYYY HH:MM", "MM/DD/YYYY HH:MM:SS",
+ "DD/MM/YYYY HH:MM", "DD/MM/YYYY HH:MM:SS",
+ "hh:mm AM/PM", "hh:mm:ss AM/PM",
+ "YYYY-MM-DD hh:mm AM/PM", "YYYY-MM-DD hh:mm:ss AM/PM",
+ "YYYY-MM-DDTHH:MM:SS", "YYYY-MM-DDTHH:MM:SSZ"
+})
private com.testsigma.sdk.TestDataParameter timeFormat;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| @TestDataFunctionParameter(reference = "test-data") | |
| private com.testsigma.sdk.TestDataParameter testData; | |
| @TestDataFunctionParameter(reference = "time-amount") | |
| private com.testsigma.sdk.TestDataParameter timeAmount; | |
| @TestDataFunctionParameter(reference = "time-unit") | |
| private com.testsigma.sdk.TestDataParameter timeUnit; | |
| @TestDataFunctionParameter(reference = "time-format") | |
| private com.testsigma.sdk.TestDataParameter timeFormat; | |
| @TestDataFunctionParameter(reference = "test-data") | |
| private com.testsigma.sdk.TestDataParameter testData; | |
| @TestDataFunctionParameter(reference = "time-amount") | |
| private com.testsigma.sdk.TestDataParameter timeAmount; | |
| @TestDataFunctionParameter(reference = "time-unit", allowedValues = {"SECONDS", "MINUTES", "HOURS", "DAYS", "WEEKS", "MONTHS", "YEARS"}) | |
| private com.testsigma.sdk.TestDataParameter timeUnit; | |
| @TestDataFunctionParameter(reference = "time-format", allowedValues = { | |
| "HH:MM", "HH:MM:SS", | |
| "YYYY-MM-DD", "DD-MM-YYYY", "MM/DD/YYYY", "DD/MM/YYYY", | |
| "YYYY-MM-DD HH:MM", "YYYY-MM-DD HH:MM:SS", | |
| "DD-MM-YYYY HH:MM", "DD-MM-YYYY HH:MM:SS", | |
| "MM/DD/YYYY HH:MM", "MM/DD/YYYY HH:MM:SS", | |
| "DD/MM/YYYY HH:MM", "DD/MM/YYYY HH:MM:SS", | |
| "hh:mm AM/PM", "hh:mm:ss AM/PM", | |
| "YYYY-MM-DD hh:mm AM/PM", "YYYY-MM-DD hh:mm:ss AM/PM", | |
| "YYYY-MM-DDTHH:MM:SS", "YYYY-MM-DDTHH:MM:SSZ" | |
| }) | |
| private com.testsigma.sdk.TestDataParameter timeFormat; |
🤖 Prompt for AI Agents
In
date_time_utilities/src/main/java/com/testsigma/addons/DataGenerators/AddTimeToGivenTime.java
around lines 18 to 25, the TestDataFunctionParameter annotations for time-unit
and time-format lack allowedValues which leaves users guessing; add
allowedValues arrays to both parameters to mirror the web action options (e.g.
for time-unit: {"SECONDS","MINUTES","HOURS","DAYS"} and for time-format:
{"HH:mm","hh:mm a","HH:mm:ss","ISO_LOCAL_TIME"} or the exact format list used by
the corresponding web action). Update the two @TestDataFunctionParameter
annotations to include the allowedValues property so the UI shows the available
choices.
| @TestDataFunctionParameter(reference = "time-format") | ||
| private com.testsigma.sdk.TestDataParameter timeFormat; |
There was a problem hiding this comment.
Add allowedValues annotation to guide users on supported formats.
Unlike the web action version, this data generator doesn't specify allowedValues for the time-format parameter. This means users won't see a dropdown of valid format options in the UI, making it harder to use correctly.
Apply this diff to add the allowedValues annotation:
-@TestDataFunctionParameter(reference = "time-format")
+@TestDataFunctionParameter(reference = "time-format", allowedValues = {
+ "UTC",
+ "ISO_8601",
+ "HH:MM", "HH:MM:SS", "hh:mm AM/PM", "hh:mm:ss AM/PM",
+ "YYYY-MM-DD", "DD-MM-YYYY", "MM/DD/YYYY", "DD/MM/YYYY",
+ "YYYY-MM-DD HH:MM", "YYYY-MM-DD HH:MM:SS",
+ "DD-MM-YYYY HH:MM", "DD-MM-YYYY HH:MM:SS",
+ "MM/DD/YYYY HH:MM", "MM/DD/YYYY HH:MM:SS",
+ "DD/MM/YYYY HH:MM", "DD/MM/YYYY HH:MM:SS",
+ "YYYY-MM-DD hh:mm AM/PM", "YYYY-MM-DD hh:mm:ss AM/PM",
+ "YYYY-MM-DDTHH:MM:SS", "YYYY-MM-DDTHH:MM:SSZ"
+})
private com.testsigma.sdk.TestDataParameter timeFormat;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| @TestDataFunctionParameter(reference = "time-format") | |
| private com.testsigma.sdk.TestDataParameter timeFormat; | |
| @TestDataFunctionParameter(reference = "time-format", allowedValues = { | |
| "UTC", | |
| "ISO_8601", | |
| "HH:MM", "HH:MM:SS", "hh:mm AM/PM", "hh:mm:ss AM/PM", | |
| "YYYY-MM-DD", "DD-MM-YYYY", "MM/DD/YYYY", "DD/MM/YYYY", | |
| "YYYY-MM-DD HH:MM", "YYYY-MM-DD HH:MM:SS", | |
| "DD-MM-YYYY HH:MM", "DD-MM-YYYY HH:MM:SS", | |
| "MM/DD/YYYY HH:MM", "MM/DD/YYYY HH:MM:SS", | |
| "DD/MM/YYYY HH:MM", "DD/MM/YYYY HH:MM:SS", | |
| "YYYY-MM-DD hh:mm AM/PM", "YYYY-MM-DD hh:mm:ss AM/PM", | |
| "YYYY-MM-DDTHH:MM:SS", "YYYY-MM-DDTHH:MM:SSZ" | |
| }) | |
| private com.testsigma.sdk.TestDataParameter timeFormat; |
🤖 Prompt for AI Agents
In
date_time_utilities/src/main/java/com/testsigma/addons/DataGenerators/StoreCurrentUTCTime.java
around lines 17 to 18, the TestDataFunctionParameter for time-format lacks an
allowedValues annotation so users don't get a dropdown of supported formats; add
an allowedValues attribute to the annotation listing the valid format strings
(e.g., "ISO8601", "RFC1123", "yyyy-MM-dd'T'HH:mm:ss'Z'", "yyyy-MM-dd HH:mm:ss",
"HH:mm:ss") or the actual set of supported formats used by the generator so the
UI shows those options.
| public static class DetectedFormat { | ||
| public String formatStr; | ||
| public FormatType type; | ||
| public DateTimeFormatter formatter; | ||
|
|
||
| public DetectedFormat(String formatStr, FormatType type, DateTimeFormatter formatter) { | ||
| this.formatStr = formatStr; | ||
| this.type = type; | ||
| this.formatter = formatter; | ||
| } | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Add proper encapsulation to DetectedFormat class.
The DetectedFormat class exposes public mutable fields, which breaks encapsulation and allows external code to modify the internal state. This can lead to unexpected behavior and makes the class harder to maintain.
Apply this diff to add proper getters and make fields private:
public static class DetectedFormat {
- public String formatStr;
- public FormatType type;
- public DateTimeFormatter formatter;
+ private final String formatStr;
+ private final FormatType type;
+ private final DateTimeFormatter formatter;
public DetectedFormat(String formatStr, FormatType type, DateTimeFormatter formatter) {
this.formatStr = formatStr;
this.type = type;
this.formatter = formatter;
}
+
+ public String getFormatStr() {
+ return formatStr;
+ }
+
+ public FormatType getType() {
+ return type;
+ }
+
+ public DateTimeFormatter getFormatter() {
+ return formatter;
+ }
}Note: This will require updating all usages of DetectedFormat to use getters instead of direct field access.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| public static class DetectedFormat { | |
| public String formatStr; | |
| public FormatType type; | |
| public DateTimeFormatter formatter; | |
| public DetectedFormat(String formatStr, FormatType type, DateTimeFormatter formatter) { | |
| this.formatStr = formatStr; | |
| this.type = type; | |
| this.formatter = formatter; | |
| } | |
| } | |
| public static class DetectedFormat { | |
| private final String formatStr; | |
| private final FormatType type; | |
| private final DateTimeFormatter formatter; | |
| public DetectedFormat(String formatStr, FormatType type, DateTimeFormatter formatter) { | |
| this.formatStr = formatStr; | |
| this.type = type; | |
| this.formatter = formatter; | |
| } | |
| public String getFormatStr() { | |
| return formatStr; | |
| } | |
| public FormatType getType() { | |
| return type; | |
| } | |
| public DateTimeFormatter getFormatter() { | |
| return formatter; | |
| } | |
| } |
🤖 Prompt for AI Agents
In date_time_utilities/src/main/java/com/testsigma/addons/util/TimeUtil.java
around lines 22 to 32, the DetectedFormat inner class currently exposes public
mutable fields which breaks encapsulation; make the fields private (preferably
private final), add public getter methods for each field (getFormatStr(),
getType(), getFormatter()), keep the constructor to initialize the fields, and
optionally mark the class final; after this change, update all call sites to use
the getters instead of direct field access.
| public static FormatType getFormatType(String formatStr) { | ||
| if (formatStr.equals("HH:MM") || formatStr.equals("HH:MM:SS") || | ||
| formatStr.equals("hh:mm AM/PM") || formatStr.equals("hh:mm:ss AM/PM")) { | ||
| return FormatType.TIME_ONLY; | ||
| } else if (formatStr.equals("YYYY-MM-DD") || formatStr.equals("DD-MM-YYYY") || | ||
| formatStr.equals("MM/DD/YYYY") || formatStr.equals("DD/MM/YYYY")) { | ||
| return FormatType.DATE_ONLY; | ||
| } else { | ||
| return FormatType.DATETIME; | ||
| } | ||
| } |
There was a problem hiding this comment.
Add support for "UTC" and "ISO_8601" formats.
The getFormatType() method doesn't recognize "UTC" and "ISO_8601" formats, yet these are included in the allowedValues for StoreCurrentUTCTime classes. This inconsistency will cause runtime failures when users select these formats in actions that call getFormatType().
Apply this diff to add support for these formats:
public static FormatType getFormatType(String formatStr) {
+ if (formatStr.equals("UTC") || formatStr.equals("ISO_8601")) {
+ return FormatType.DATETIME;
+ } else if (formatStr.equals("HH:MM") || formatStr.equals("HH:MM:SS") ||
- if (formatStr.equals("HH:MM") || formatStr.equals("HH:MM:SS") ||
formatStr.equals("hh:mm AM/PM") || formatStr.equals("hh:mm:ss AM/PM")) {
return FormatType.TIME_ONLY;
} else if (formatStr.equals("YYYY-MM-DD") || formatStr.equals("DD-MM-YYYY") ||
formatStr.equals("MM/DD/YYYY") || formatStr.equals("DD/MM/YYYY")) {
return FormatType.DATE_ONLY;
} else {
return FormatType.DATETIME;
}
}🤖 Prompt for AI Agents
In date_time_utilities/src/main/java/com/testsigma/addons/util/TimeUtil.java
around lines 50 to 60, getFormatType currently doesn't recognize the "UTC" and
"ISO_8601" format strings which causes runtime failures; update the conditional
checks to treat "UTC" and "ISO_8601" as FormatType.DATETIME (add them to the
else-if branch that returns DATETIME or add an explicit check returning
DATETIME), and also make the method null-safe by guarding against a null
formatStr (e.g., return DATETIME or throw a clear exception if formatStr is
null) so callers selecting those allowedValues won't fail at runtime.
| public static LocalDateTime parseTime(String inputTimeStr) throws IllegalArgumentException { | ||
| DetectedFormat detectedInput = detectInputFormat(inputTimeStr); | ||
| String detectedInputFormatStr = detectedInput.formatStr; | ||
|
|
||
| // Parse the input time based on the detected format | ||
| if (detectedInput.type == FormatType.TIME_ONLY) { | ||
| LocalTime timeOnly = LocalTime.parse(inputTimeStr, detectedInput.formatter); | ||
| return LocalDateTime.of(LocalDate.now(), timeOnly); | ||
| } else if (detectedInput.type == FormatType.DATE_ONLY) { | ||
| LocalDate dateOnly = LocalDate.parse(inputTimeStr, detectedInput.formatter); | ||
| return dateOnly.atStartOfDay(); | ||
| } else { | ||
| // Handle ISO format with Z | ||
| if (detectedInputFormatStr.equals("YYYY-MM-DDTHH:MM:SSZ")) { | ||
| String withoutZ = inputTimeStr.replace("Z", ""); | ||
| return LocalDateTime.parse(withoutZ, detectedInput.formatter); | ||
| } else { | ||
| return LocalDateTime.parse(inputTimeStr, detectedInput.formatter); | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
Add input validation to prevent null or empty string inputs.
The method doesn't validate the input parameter before processing, which can lead to unclear error messages or NullPointerException.
Apply this diff to add input validation:
public static LocalDateTime parseTime(String inputTimeStr) throws IllegalArgumentException {
+ if (inputTimeStr == null || inputTimeStr.trim().isEmpty()) {
+ throw new IllegalArgumentException("Input time string cannot be null or empty");
+ }
+
DetectedFormat detectedInput = detectInputFormat(inputTimeStr);
String detectedInputFormatStr = detectedInput.formatStr;🤖 Prompt for AI Agents
In date_time_utilities/src/main/java/com/testsigma/addons/util/TimeUtil.java
around lines 144 to 164, the parseTime method does not validate the input string
and may throw NullPointerException or produce unclear errors; add a defensive
check at the start to ensure inputTimeStr is not null or blank (use trim() to
detect whitespace-only), and if it is, throw an IllegalArgumentException with a
clear message like "inputTimeStr must not be null or empty"; then proceed to
call detectInputFormat and the existing parsing logic using the validated (and
possibly trimmed) string.
please review these addons and publish as PUBLIC
Addon name : date_time_utilities
Addon accont: https://jarvis.testsigma.com/ui/tenants/3072/addons
Jira: https://testsigma.atlassian.net/browse/CUS-8390
fix
Added 2 NLP's
Summary by CodeRabbit