Skip to content

Parsing a timestamp from a log file but no datepart defaults to first day of the year #46111

@clever-trevor

Description

@clever-trevor

Component(s)

No response

What happened?

Description

We are monitoring a logfile which has only a timestamp in the log entry:
11:31:06,491 |-INFO in ch.qos.logback.classic.AsyncAppender[asyncFileIgnite] - Setting discardingThreshold to 10

In the collector config, we are extracting the timestamp and associated strptime pattern:
` operators:

  - type: regex_parser
    on_error: send_quiet
    regex: '^.{0,128}?(?P<timestamp>\d{2}:\d{2}:\d{2}\,\d{3})'
  - type : time_parser
    on_error: send_quiet
    parse_from: attributes.timestamp
    layout_typ: strptime
    layout: '%H:%M:%S,%L'`

However, this causes the date to be set to 01/01/2026, instead of assuming today's date.
Extract from collector debug:
ObservedTimestamp: 2026-02-16 11:48:14.016024 +0000 UTC Timestamp: 2026-01-01 11:31:06.491 +0000 UTC

Steps to Reproduce

Create a filelog watcher which has a timestamp format as shown above with a debug exporter.
Create a log entry with current time and observer the debug log which uses an old date.

Expected Result

If a date is missing, the collector should assume current data from now() function, or at least have an option in the operator to opt in for this behaviour.

Actual Result

Timestamp defaults date to first day of the year.

Collector version

v0.127.0

Environment information

Environment

OS: Confirmed on Centos 8 and MacOS

OpenTelemetry Collector configuration

receivers:
  filelog/bootaccess:
    include:
    - /Users/zzz/logs1/tomcat/instance_*/bootaccess.log
    include_file_path: true
    include_file_name: true
    poll_interval: 1s
    resource:
      collector: otel-collector
    retry_on_failure:
      enabled: true
    operators:
      - type: regex_parser
        on_error: send_quiet
        regex: '^.{0,128}?(?P<timestamp>\d{2}:\d{2}:\d{2}\,\d{3})'
      - type : time_parser
        on_error: send_quiet
        parse_from: attributes.timestamp
        layout_typ: strptime
        layout: '%H:%M:%S,%L'
      - type: remove
        on_error: send_quiet
        field: attributes.timestamp

exporters:
  debug:
    verbosity: detailed

service:
  pipelines:
    logs/global_files:
      receivers: [filelog/bootaccess,]
      processors: []
      exporters: [debug]

Log output

{"level":"info","ts":"2026-02-16T11:48:14.114Z","msg":"ResourceLog #0\nResource SchemaURL: https://opentelemetry.io/schemas/1.6.1\nResource attributes:\n     -> collector: Str(otel-collector)\n     -> sourcetype: Str(zzz)\n     -> service.namespace: Str(zzz)\n     -> service.name: Str(zzz)\n     -> host.name: Str(zzz)\n     -> os.type: Str(darwin)\n     -> deployment.site: Str(test)\n     -> service.instance.id: Str(zzz)\nScopeLogs #0\nScopeLogs SchemaURL: \nInstrumentationScope  \nLogRecord #0\nObservedTimestamp: 2026-02-16 11:48:14.016024 +0000 UTC\nTimestamp: 2026-01-01 11:31:06.491 +0000 UTC\nSeverityText: \nSeverityNumber: Unspecified(0)\nBody: Str(11:31:06,491 |-INFO in ch.qos.logback.classic.AsyncAppender[asyncFileIgnite] - Setting discardingThreshold to 10)\nAttributes:\n     -> log.file.name: Str(bootaccess.log)\n     -> log.file.path: Str(/Users/zzz/logs1/tomcat/instance_1/bootaccess.log)\n     -> collector: Str(otel-collector)\nTrace ID: \nSpan ID: \nFlags: 0\n","resource":{},"otelcol.component.id":"debug","otelcol.component.kind":"exporter","otelcol.signal":"logs"}

Additional context

This was previously reported under issue 30683 but closed with comments about not being able to determine which part of a date to replace if only a partial match was made.

In this case, there is no date part so it should be a clear (and logical) decision to revert to today's date.

Tip

React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions