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
   */
  @VisibleForTesting

View on GitHub (pinned to fb949e2676)

Solutions

  1. Provide a full ISO 8601 date-time with time and offset, e.g. 2023-01-15T10:00:00Z.
  2. Use the literal value EPOCH_PLUS_SECOND if a deterministic early timestamp is intended.
  3. 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

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


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