LFS locks "locked_at": inconsistent precision + LFS spec violation

[slonopotamus]

• Gitea version (or commit ref): 1.10.0+dev-156-g8101d803e
• Git version: 2.22.0, though doesn't matter
• Operating system: Linux, though doesn't matter
• Can you reproduce the bug at https://try.gitea.io:
  No (try.gitea.io is down), but I can reproduce it on https://gitea.com
• Log gist:

$ git clone [email protected]:slonopotamus/gitea-blog.git
Cloning into 'gitea-blog'...
remote: Enumerating objects: 777, done.
remote: Counting objects: 100% (777/777), done.
remote: Compressing objects: 100% (343/343), done.
remote: Total 777 (delta 318), reused 726 (delta 299)
Receiving objects: 100% (777/777), 4.26 MiB | 1.46 MiB/s, done.
Resolving deltas: 100% (318/318), done.

$ cd gitea-blog

$ GIT_TRACE=1 git lfs lock Makefile 
23:49:19.390102 git.c:704               trace: exec: git-lfs lock Makefile
23:49:19.390122 run-command.c:663       trace: run_command: git-lfs lock Makefile
23:49:19.392307 trace git-lfs: exec: git 'version'
23:49:19.393810 trace git-lfs: exec: git '-c' 'filter.lfs.smudge=' '-c' 'filter.lfs.clean=' '-c' 'filter.lfs.process=' '-c' 'filter.lfs.required=false' 'rev-parse' 'HEAD' '--symbolic-full-name' 'HEAD'
23:49:19.395162 trace git-lfs: exec: git 'config' '-l'
23:49:19.395913 trace git-lfs: run_command: ssh -- [email protected] git-lfs-authenticate slonopotamus/gitea-blog.git upload
23:49:20.215639 trace git-lfs: HTTP: POST https://gitea.com/slonopotamus/gitea-blog.git/info/lfs/locks
23:49:21.521682 trace git-lfs: HTTP: 201
23:49:21.521743 trace git-lfs: HTTP: {"lock":{"id":"2","path":"Makefile","locked_at":"2019-08-14T20:49:21.392551447Z","owner":{"name":"slonopotamus"}}}
Locked Makefile
23:49:21.523013 trace git-lfs: filepathfilter: rewrite ".git" as "**/.git/**"
23:49:21.523026 trace git-lfs: filepathfilter: rewrite "**/.git" as "**/.git"
23:49:21.523060 trace git-lfs: filepathfilter: accepting "tmp"

$ GIT_TRACE=1 git lfs locks
23:49:24.582212 git.c:704               trace: exec: git-lfs locks
23:49:24.582235 run-command.c:663       trace: run_command: git-lfs locks
23:49:24.584455 trace git-lfs: exec: git 'version'
23:49:24.585256 trace git-lfs: exec: git '-c' 'filter.lfs.smudge=' '-c' 'filter.lfs.clean=' '-c' 'filter.lfs.process=' '-c' 'filter.lfs.required=false' 'rev-parse' 'HEAD' '--symbolic-full-name' 'HEAD'
23:49:24.586718 trace git-lfs: exec: git 'config' '-l'
23:49:24.587855 trace git-lfs: run_command: ssh -- [email protected] git-lfs-authenticate slonopotamus/gitea-blog.git upload
23:49:25.396155 trace git-lfs: HTTP: GET https://gitea.com/slonopotamus/gitea-blog.git/info/lfs/locks
23:49:26.614518 trace git-lfs: HTTP: 200
23:49:26.614583 trace git-lfs: HTTP: {"locks":[{"id":"2","path":"Makefile","locked_at":"2019-08-14T20:49:21Z","owner":{"name":"slonopotamus"}}]}
Makefile        slonopotamus    ID:2
23:49:26.614832 trace git-lfs: filepathfilter: rewrite ".git" as "**/.git/**"
23:49:26.614843 trace git-lfs: filepathfilter: rewrite "**/.git" as "**/.git"
23:49:26.614875 trace git-lfs: filepathfilter: accepting "tmp"

Description

Look at "locked_at" timestamps. When lock it just created, Gitea returns timestamp with nanosecond precision: 2019-08-14T20:49:21.392551447Z. But when I am listing locks later, timestamp only has second precision: 2019-08-14T20:49:21Z

Expected: lock is always returned with same timestamp precision via LFS API. Also, LFS protocol spec clearly says that timestamp needs to have second precision.

P.S. If this bug came with code from lfs-test-server, please tell me so I open a bugreport there too.

[sapk]

The problem seems to come from that list have timestamp based on stored in database and POST the lock details come from the object unaltered so with nanosecond precision.
The fix (in coming) is to adjust func (l *LFSLock) APIFormat() *api.LFSLock to fix the time precision.