GoogleContainerTools/jib · error · InvalidFilesModificationTimeException
${modificationTime}
Error message
${modificationTime} What it means
Jib's filesModificationTime option accepts 'EPOCH_PLUS_SECOND' or an ISO 8601 date-time. createModificationTimeProvider parses the value with DateTimeFormatter.ISO_DATE_TIME; any DateTimeParseException is rethrown as InvalidFilesModificationTimeException with the configured value shown where ${modificationTime} appears.
Source
Thrown at jib-plugins-common/src/main/java/com/google/cloud/tools/jib/plugins/common/PluginConfigurationProcessor.java:929
* @throws InvalidFilesModificationTimeException if the config value is not in ISO 8601 format
*/
@VisibleForTesting
static ModificationTimeProvider createModificationTimeProvider(String modificationTime)
throws InvalidFilesModificationTimeException {
try {
switch (modificationTime) {
case "EPOCH_PLUS_SECOND":
Instant epochPlusSecond = Instant.ofEpochSecond(1);
return (ignored1, ignored2) -> epochPlusSecond;
default:
Instant timestamp =
DateTimeFormatter.ISO_DATE_TIME.parse(modificationTime, Instant::from);
return (ignored1, ignored2) -> timestamp;
}
} catch (DateTimeParseException ex) {
throw new InvalidFilesModificationTimeException(modificationTime, modificationTime, ex);
}
}
/**
* Creates an {@link Instant} based on the config value. The value can be:
*
* <ol>
* <li>{@code EPOCH} to return epoch
* <li>{@code USE_CURRENT_TIMESTAMP} to return the current time
* <li>date in ISO 8601 format
* </ol>
*
* @param configuredCreationTime the config value
* @param projectProperties used for logging warnings
* @return corresponding {@link Instant}
* @throws InvalidCreationTimeException if the config value is invalid
*/
@VisibleForTestingView on GitHub (pinned to fb949e2676)
Solutions
- Provide a full ISO 8601 date-time with time and offset, e.g. 2023-01-15T10:00:00Z.
- Use the literal value EPOCH_PLUS_SECOND if a deterministic early timestamp is intended.
- Validate the string with java.time.DateTimeFormatter.ISO_DATE_TIME.parse or Instant.parse in a local test before configuring the build.
Example fix
// before jib.container.filesModificationTime = '2023-01-15' // after jib.container.filesModificationTime = '2023-01-15T10:00:00Z'
Defensive patterns
Strategy: validation
Validate before calling
// Validate modification time value before configuring Jib
if (!modificationTime.equals("EPOCH_PLUS_SECOND")) {
java.time.Instant.parse(modificationTime); // throws if not ISO 8601 instant
} Try / catch
try {
processCommonConfiguration(...);
} catch (InvalidFilesModificationTimeException e) {
logger.error("Bad filesModificationTime '" + e.getInvalidFilesModificationTime()
+ "'; use EPOCH_PLUS_SECOND or ISO 8601 like 2023-01-15T10:00:00Z");
} Prevention
- Use full ISO 8601 instants with 'Z' or an offset
- Prefer the literal EPOCH_PLUS_SECOND for reproducible builds
- Test date strings with Instant.parse in a scratch build first
When it happens
Trigger: processCommonConfiguration -> createModificationTimeProvider when the configured modification time is neither the literal 'EPOCH_PLUS_SECOND' nor parseable by ISO_DATE_TIME (e.g. missing timezone, wrong format).
Common situations: Using human formats like '2023-01-15' (date only, lacks time) or '2023-01-15 10:00:00' (space instead of T, no offset); misspelling EPOCH_PLUS_SECOND; build-tool interpolation yielding a placeholder string.
Related errors
- ${configuredCreationTime}
- platform configuration is missing an OS value
- ${path}
- ${appRoot}
- packaged containerizing mode for WAR is not yet supported
AI-assisted analysis of GoogleContainerTools/jib@fb949e2676 (2026-09-06).
Data as JSON: /api/errors/543525533c950a7d.
Report an issue: GitHub.