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

  1. Use a complete ISO 8601 instant such as 2023-06-01T12:00:00Z (include a timezone offset).
  2. Use the literals EPOCH or USE_CURRENT_TIMESTAMP when a dynamic time is desired, spelled exactly.
  3. 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

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


AI-assisted analysis of GoogleContainerTools/jib@fb949e2676 (2026-09-06). Data as JSON: /api/errors/b7a9190705e43f81. Report an issue: GitHub.