start_time in _replicate response not using UTC

[skeyby]

Invoking the _replicate API endpoint, the JSON response reports a wrong start time - on our server it's 1 hour back in time.

Expected Behavior

start_time should be correct time :)

Current Behavior

after creating two database with just a single document and invoking a single one shot replication for the specific doc id of the document this is the response:

{
"ok": true,
"session_id": "4ae02b10379bd5e8cb4b0ee5eff03275",
"source_last_seq": "1-g1AAAAIReJyVz10OgjAMAOAqJuqjJ9ATGMb4mU9yE-3oFiSITzzrTfQmehO9CQ4xARKDkCVd0rVfuxQAZrFFsIhOeRSTDJkTrG1zWGqexghyWRRFElsIR5OY2n6AXAQE8zwjpQ-Zoo52uTJRbr_C6CP46CnJxa-eLikspV1rF47CkUz13WVfCueWsNHCJZI9hWxiIlzMZZBrrRBqxpU_SLlVyj1B-Fv7qGqf9USHuQxdPWjiq1Iavxfocy_iTSV5A4-ckCc",
"replication_id_version": 4,
"start_time": "Thu, 03 Jan 2019 15:43:48 GMT",
"end_time": "Thu, 03 Jan 2019 16:43:55 GMT",
"docs_read": 1,
"docs_written": 1,
"doc_write_failures": 0,
"history": [
{
"session_id": "4ae02b10379bd5e8cb4b0ee5eff03275",
"start_time": "Thu, 03 Jan 2019 15:43:48 GMT",
"end_time": "Thu, 03 Jan 2019 16:43:55 GMT",
"start_last_seq": 0,
"end_last_seq": "1-g1AAAAIReJyVz10OgjAMAOAqJuqjJ9ATGMb4mU9yE-3oFiSITzzrTfQmehO9CQ4xARKDkCVd0rVfuxQAZrFFsIhOeRSTDJkTrG1zWGqexghyWRRFElsIR5OY2n6AXAQE8zwjpQ-Zoo52uTJRbr_C6CP46CnJxa-eLikspV1rF47CkUz13WVfCueWsNHCJZI9hWxiIlzMZZBrrRBqxpU_SLlVyj1B-Fv7qGqf9USHuQxdPWjiq1Iavxfocy_iTSV5A4-ckCc",
"recorded_seq": "1-g1AAAAIReJyVz10OgjAMAOAqJuqjJ9ATGMb4mU9yE-3oFiSITzzrTfQmehO9CQ4xARKDkCVd0rVfuxQAZrFFsIhOeRSTDJkTrG1zWGqexghyWRRFElsIR5OY2n6AXAQE8zwjpQ-Zoo52uTJRbr_C6CP46CnJxa-eLikspV1rF47CkUz13WVfCueWsNHCJZI9hWxiIlzMZZBrrRBqxpU_SLlVyj1B-Fv7qGqf9USHuQxdPWjiq1Iavxfocy_iTSV5A4-ckCc",
"missing_checked": 1,
"missing_found": 1,
"docs_read": 1,
"docs_written": 1,
"doc_write_failures": 0
}
]
}

As you can see even if the replication job took just a few seconds there's an hour of difference between start_time and end_time.

end_time was the correct time when the test was executed.

Steps to Reproduce (for bugs)

curl -X PUT "http://127.0.0.1:5984/baseball_1"
curl -X PUT "http://127.0.0.1:5984/baseball_2"
curl -H 'Content-Type: application/json' -X POST "http://127.0.0.1:5984/baseball_1/" -d '{}'
curl -H 'Content-Type: application/json' -X POST "http://127.0.0.1:5984/_replicate" -d '{"source":{"url":"http://10.33.102.165:5984/baseball_1"},"target":{"url":"https://free.bd.gcloud.schema31.it:443/baseball_2"},"doc_ids":[*****FILL WITH THE DOCUMENT ID FROM PREVIOUS POST*****]}'

Your Environment

• Version used: 2.3.0
• Operating System and version (desktop or mobile): FreeBSD 11.2 (Erlang Runtime 21.2)

[wohali]

I can't confirm this - what is the timezone setting on your server? Erlang should be picking it up from that.

$ curl -X PUT http://127.0.0.1:15984/baseball_1
{"ok":true}
$ curl -X PUT http://127.0.0.1:15984/baseball_2
{"ok":true}
$ curl -H 'Content-Type: application/json' -X POST "http://127.0.0.1:15984/baseball_1/" -d '{}'
$ curl -H 'Content-Type: application/json' -X POST "http://127.0.0.1:15984/_replicate" -d '{"source":{"url":"http://127.0.0.1:15984/baseball_1"},"target":{"url":"https://127.0.0.1:15984/baseball_2"},"doc_ids":["41fa187659bd5957ab3d2d22a80006f4"]}'
{"ok":true,"session_id":"5ac147f405fb75b6b7107d76a14e7c30","source_last_seq":"1-g1AAAAGXeJzLYWBg4MhgTmHgz8tPSTV0MDQy1zMAQsMcoARTIkOS_P___7MymBMZcoEC7BYGlommhhYpDJyleSmpaZl5qSk4NScpAMkke5D-RAbcqhxAquIJqUoAqaonoCqPBUgyNAApoML5hFUugKjcj_CfUWJKqhGR_oOYcQBixn2QGYxgM0wtzC0tk4wwdREw6QHEJJAPswD_amrS","replication_id_version":4,"start_time":"Mon, 07 Jan 2019 21:35:51 GMT","end_time":"Mon, 07 Jan 2019 16:35:56 GMT","docs_read":1,"docs_written":1,"doc_write_failures":0,"history":[{"session_id":"5ac147f405fb75b6b7107d76a14e7c30","start_time":"Mon, 07 Jan 2019 21:35:51 GMT","end_time":"Mon, 07 Jan 2019 16:35:56 GMT","start_last_seq":0,"end_last_seq":"1-g1AAAAGXeJzLYWBg4MhgTmHgz8tPSTV0MDQy1zMAQsMcoARTIkOS_P___7MymBMZcoEC7BYGlommhhYpDJyleSmpaZl5qSk4NScpAMkke5D-RAbcqhxAquIJqUoAqaonoCqPBUgyNAApoML5hFUugKjcj_CfUWJKqhGR_oOYcQBixn2QGYxgM0wtzC0tk4wwdREw6QHEJJAPswD_amrS","recorded_seq":"1-g1AAAAGXeJzLYWBg4MhgTmHgz8tPSTV0MDQy1zMAQsMcoARTIkOS_P___7MymBMZcoEC7BYGlommhhYpDJyleSmpaZl5qSk4NScpAMkke5D-RAbcqhxAquIJqUoAqaonoCqPBUgyNAApoML5hFUugKjcj_CfUWJKqhGR_oOYcQBixn2QGYxgM0wtzC0tk4wwdREw6QHEJJAPswD_amrS","missing_checked":1,"missing_found":1,"docs_read":1,"docs_written":1,"doc_write_failures":0}]}
[688 atypical:joant ~] $ date -u
Mon Jan  7 16:36:47 UTC 2019

Obviously the recommendation is to run with your server set to UTC.

[skeyby]

$ date -u
Mon Jan  7 17:53:08 UTC 2019
$ date
Mon Jan  7 18:53:10 CET 2019

The server is in GMT+1, we're in Rome.

[skeyby]

Sorry Joan but your example confirm my report. Maybe I didn't explain myself correctly.

"start_time":"Mon, 07 Jan 2019 21:35:51 GMT","end_time":"Mon, 07 Jan 2019 16:35:56 GMT"

Your End Time is 5 hours before your start time.

Maybe your replication was called Delorean :-)

[wohali]

Ah, this is because the shell from which I launched CouchDB has my TZ set to EST5EDT:

$ echo $TZ
EST5EDT

which is overriding /etc/timezone.

Check the TZ variable for your launch process for CouchDB. If you launched this from the command line, you may have your local

If you're on Linux, you can confirm this by looking in /proc/<pid-of-couchdb>/environ.

Not saying this is fixed, just a workaround.

[wohali]

@nickva looks like we have a TZ problem

[nickva]

@skeyby Thank you for the report!

@wohali , indeed seems like a bug, thanks for digging in and debugging it. I'll assign the ticket to me.

[skeyby]

Ah, this is because the shell from which I launched CouchDB has my TZ set to EST5EDT:

$ echo $TZ
EST5EDT

which is overriding /etc/timezone.

Check the TZ variable for your launch process for CouchDB. If you launched this from the command line, you may have your local

If you're on Linux, you can confirm this by looking in /proc/<pid-of-couchdb>/environ.

Not saying this is fixed, just a workaround.

Hi Joan. Just as a general note, FreeBSD neither have /etc/timezone or $TZ environment variable.

I guess Erlang is finding the correct timezone somehow else.

Thanks.

[wohali]

Hi @skeyby ,

Ah, didn't realize you were on FreeBSD. In this case it's using what's at /etc/localtime:

cd /usr/share/zoneinfo/ && find * -type f -exec cmp -s {} /etc/localtime \; -print;

will tell you what you have it set to.

You can simply cp /usr/share/zoneinfo/UTC /etc/localtime to work around this for now if you want. Of course, all times in your shell will now be in UTC instead of in GMT+1.

[nickva]

@skeyby @wohali I tried to fix it in #1845 give it a try and see if it works on your machines