GoogleContainerTools/jib · error · InvalidCreationTimeException
${configuredCreationTime}
Error message
${configuredCreationTime} What it means
Jib's creationTime option accepts 'EPOCH', 'USE_CURRENT_TIMESTAMP', or an ISO 8601 date-time. getCreationTime parses custom values with a strict ISO_DATE_TIME formatter (relaxed only to allow +HHmm offsets); a DateTimeParseException is wrapped in InvalidCreationTimeException with the configured value shown where ${configuredCreationTime} appears.
Source
Thrown at jib-plugins-common/src/main/java/com/google/cloud/tools/jib/plugins/common/PluginConfigurationProcessor.java:973
case "USE_CURRENT_TIMESTAMP":
projectProperties.log(
LogEvent.debug(
"Setting image creation time to current time; your image may not be reproducible."));
return Instant.now();
default:
DateTimeFormatter formatter =
new DateTimeFormatterBuilder()
.append(DateTimeFormatter.ISO_DATE_TIME) // parses isoStrict
// add ability to parse with no ":" in tz
.optionalStart()
.appendOffset("+HHmm", "+0000")
.optionalEnd()
.toFormatter();
return formatter.parse(configuredCreationTime, Instant::from);
}
} catch (DateTimeParseException ex) {
throw new InvalidCreationTimeException(configuredCreationTime, configuredCreationTime, ex);
}
}
// TODO: find a way to reduce the number of arguments.
private static void configureCredentialRetrievers(
RawConfiguration rawConfiguration,
ProjectProperties projectProperties,
RegistryImage registryImage,
ImageReference imageReference,
String usernamePropertyName,
String passwordPropertyName,
AuthProperty rawAuthConfiguration,
InferredAuthProvider inferredAuthProvider,
CredHelperConfiguration credHelperConfiguration)
throws FileNotFoundException {
DefaultCredentialRetrievers defaultCredentialRetrievers =
DefaultCredentialRetrievers.init(
CredentialRetrieverFactory.forImage(View on GitHub (pinned to fb949e2676)
Solutions
- Use a complete ISO 8601 instant such as 2023-06-01T12:00:00Z (include a timezone offset).
- Use the literals EPOCH or USE_CURRENT_TIMESTAMP when a dynamic time is desired, spelled exactly.
- Check build logs/config for unresolved interpolation (e.g. literal ${git.commit.time}) and bind a real value.
Example fix
// before jib.container.creationTime = '2023-06-01T12:00:00' // after jib.container.creationTime = '2023-06-01T12:00:00Z'
Defensive patterns
Strategy: validation
Validate before calling
// Validate creation time before configuring Jib
if (!configuredCreationTime.equals("EPOCH")
&& !configuredCreationTime.equals("USE_CURRENT_TIMESTAMP")) {
java.time.Instant.parse(configuredCreationTime); // throws if not ISO 8601 instant
} Try / catch
try {
processCommonConfiguration(...);
} catch (InvalidCreationTimeException e) {
logger.error("Bad creationTime '" + e.getInvalidCreationTime()
+ "'; use EPOCH, USE_CURRENT_TIMESTAMP, or ISO 8601 with offset");
} Prevention
- Include timezone in custom creation times (e.g. ...T12:00:00Z)
- Spell literals EPOCH and USE_CURRENT_TIMESTAMP exactly
- Check for unresolved ${...} placeholders in build config
When it happens
Trigger: processCommonConfiguration -> getCreationTime when the configured creation time is not one of the special literals and fails formatter.parse(..., Instant::from) — wrong format, missing offset, or invalid date.
Common situations: Setting creationTime to a plain date '2023-06-01'; using local date-time without zone like '2023-06-01T12:00:00'; environment-specific property expansion leaving a literal '${...}' placeholder; typos in EPOCH/USE_CURRENT_TIMESTAMP.
Related errors
- ${modificationTime}
- 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/b7a9190705e43f81.
Report an issue: GitHub.