'podman ps --format json' no longer has a numeric UNIX timestamp in "Created"

[debarshiray]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

podman ps --format json no longer has a numeric UNIX timestamp in Created. In the release candidates for Podman 3.0.0, it's a string that looks like "2021-01-19T19:17:40.179387486+01:00". Earlier, in Podman 2.2.1, it used to be a number that would get parsed as a float64.

Note that:

• podman images --format json continues to have a numeric UNIX timestamp in Created, and this particular encoding for containers was discussed during the Podman 2.x timeframe in Json output of podman ps lacks a human-readable time of creation #6594.

• Toolbox doesn't use the CreatedAt fields. So this string representation in podman ps can be moved to CreatedAt because that will make it consistent with podman images.

Steps to reproduce the issue:

1. $ podman ps --all --format json | less

Describe the results you received:

Created is a string.

Describe the results you expected:

Created should've been a numeric UNIX timestamp.

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

Version:      3.0.0-rc3
API Version:  3.0.0
Go Version:   go1.15.7
Built:        Mon Feb  8 22:16:50 2021
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.19.2
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.0.21-3.fc33.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.21, commit: 0f53fb68333bdead5fe4dc5175703e22cf9882ab'
  cpus: 4
  distribution:
    distribution: fedora
    version: "33"
  eventLogger: journald
  hostname: kolache
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.10.13-200.fc33.x86_64
  linkmode: dynamic
  memFree: 124710912
  memTotal: 8102649856
  ociRuntime:
    name: crun
    package: crun-0.17-1.fc33.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.17
      commit: 0e9229ae34caaebcb86f1fde18de3acaf18c6d9a
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    selinuxEnabled: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.8-1.fc33.x86_64
    version: |-
      slirp4netns version 1.1.8
      commit: d361001f495417b880f20329121e3aa431a8f90f
      libslirp: 4.3.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.0
  swapFree: 7752638464
  swapTotal: 8184127488
  uptime: 11h 45m 23.97s (Approximately 0.46 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - docker.io
store:
  configFile: /home/rishi/.config/containers/storage.conf
  containerStore:
    number: 2
    paused: 0
    running: 2
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.4.0-1.fc33.x86_64
      Version: |-
        fusermount3 version: 3.9.3
        fuse-overlayfs: version 1.4
        FUSE library version 3.9.3
        using FUSE kernel interface version 7.31
  graphRoot: /home/rishi/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 7
  runRoot: /run/user/1000/containers
  volumePath: /home/rishi/.local/share/containers/storage/volumes
version:
  APIVersion: 3.0.0
  Built: 1612819010
  BuiltTime: Mon Feb  8 22:16:50 2021
  GitCommit: ""
  GoVersion: go1.15.7
  OsArch: linux/amd64
  Version: 3.0.0-rc3

Package info (e.g. output of rpm -q podman or apt list podman):

podman-3.0.0-0.5.rc3.fc33.x86_64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

Yes

[afbjorklund]

Changed in 2d861ac, which modified the output format as well as the internal representation.

[mheon]

@rhatdan PTAL

[baude]

@afbjorklund did you intend to have the output format modified as well?

[afbjorklund]

@afbjorklund did you intend to have the output format modified as well?

It was not me (but rhatdan) - just digged it up in log, and it looked unintentional

Should be straightforward to make it more similar to the images list, I think ?

		Created:   conConfig.CreatedTime.Unix(),
		CreatedAt: conConfig.CreatedTime,

But you seem to be having something else going on there already

[rhatdan]

The goal was to be more precise then just Unix() which returns EPOCH Seconds. As I recall there were tests that we sorting two containers, that we definitely created one after the other, but created in the same second. So sorting them would randomly put one before the other. Getting to more precision eliminated this problem.

[debarshiray]

Yay! Thanks for the fix.

[debarshiray]

Oops, on closer inspection, I see that #9320 changed Create to a UNIX timestamp in nanoseconds, while earlier in 2.2.1 it used to be in seconds. This throws off Toolbox's parsing because it just sees a number and doesn't know if it's in seconds or nanoseconds. Is there a good way to differentiate between those?

Toolbox doesn't use the CreatedAt field in podman ps --format json. So how about repurposing that for a more precise timestamp value? It's currently inconsistent with the output from podman images --format json, anyway - it might have the nice side-effect of making them consistent.

[rhatdan]

If the number of seconds is well in the future then it is nanoseconds.

[debarshiray]

Well, one way to tell them apart is to take the timestamp value of the present moment and compare it with the number in the JSON. If the JSON value is higher then we could say that it's in nano seconds, because Created is meant to express a past event.

What I am not sure about is, how robust this will be against weird pathological cases like broken clocks and such.