Factom-cli and API report incorrect dblock timestamp for certain calls

[OrmEmbaar]

This call:

factom-cli get dbheight 144378

Contains as part of the response:

"dbhash": "6dcbd123507b51a386d16815b9159e7e68d6e383a756d123c916222ff452b8a8",
"keymr": "d750bca37731519658303f40cbfbb7ab87fad240770fa8aea3af4770334faa86",
"header": {
	"version": 0,
	"networkid": 4203931042,
	"bodymr": "63b9981e9d44ae0a3d36a23bed72cf423cf6ef956dd1b49814edc5eb57e2f03d",
	"prevkeymr": "70bdde669000bd1d67241448b3fd34f08dedc9f4627b03cef2b469528f7c945b",
	"prevfullhash": "0398c7cb74bc5c79ba3e1c976bdc5d50a467edf1e57c57e8a55ad8b8ec5b45a7",
	"timestamp": 25475055,
	"dbheight": 144378,
	"blockcount": 3,
	"chainid": "000000000000000000000000000000000000000000000000000000000000000d"
},

If you look at the timestamp, 25475055, you'll see that it is for some date in late 1970. Conversely, if you call that block hash directly with:

factom-cli get dblock 6dcbd123507b51a386d16815b9159e7e68d6e383a756d123c916222ff452b8a8

Then it returns the correct time:

PrevBlockKeyMR: 70bdde669000bd1d67241448b3fd34f08dedc9f4627b03cef2b469528f7c945b
Timestamp: 1528503300
SequenceNumber: 144378
EntryBlock {
	ChainID 000000000000000000000000000000000000000000000000000000000000000a
	KeyMR ef439af7b8bba0ecaf786f3d6b4b03977cbe1a5b66f413c1f3f7a7416ac998f4
}
EntryBlock {
	ChainID 000000000000000000000000000000000000000000000000000000000000000c
	KeyMR 95e7dcec96787519676cfd3d2951b8740763a384736eafb87ffa40af170b9aa3
}
EntryBlock {
	ChainID 000000000000000000000000000000000000000000000000000000000000000f
	KeyMR 810da0af022deb1474dfe640f4ec769f5c924a6b555a7378a6db5802d49cea29
}

[drobertbaker]

Alex: The timestamp returned by factom-cli get dblock is the standard Unix timestamp in seconds. The timestamp returned by factom-cli get dbheight is the Unix timestamp in MINUTES. If you multiply it by 60, you will see that they are the same.

…

On Tue, Jun 12, 2018 at 2:17 AM, AlexCarrithers ***@***.***> wrote: This call: factom-cli get dbheight 144378 Contains as part of the response: "dbhash": "6dcbd123507b51a386d16815b9159e7e68d6e383a756d123c916222ff452b8a8", "keymr": "d750bca37731519658303f40cbfbb7ab87fad240770fa8aea3af4770334faa86", "header": { "version": 0, "networkid": 4203931042, "bodymr": "63b9981e9d44ae0a3d36a23bed72cf423cf6ef956dd1b49814edc5eb57e2f03d", "prevkeymr": "70bdde669000bd1d67241448b3fd34f08dedc9f4627b03cef2b469528f7c945b", "prevfullhash": "0398c7cb74bc5c79ba3e1c976bdc5d50a467edf1e57c57e8a55ad8b8ec5b45a7", "timestamp": 25475055, "dbheight": 144378, "blockcount": 3, "chainid": "000000000000000000000000000000000000000000000000000000000000000d" }, If you look at the timestamp, 25475055 you'll see that it is for some date in late 1970. Conversely, if you call that block hash directly with: factom-cli get dblock 6dcbd123507b51a386d16815b9159e 7e68d6e383a756d123c916222ff452b8a8 Then it returns the correct time: PrevBlockKeyMR: 70bdde669000bd1d67241448b3fd34f08dedc9f4627b03cef2b469528f7c945b Timestamp: 1528503300 SequenceNumber: 144378 EntryBlock { ChainID 000000000000000000000000000000000000000000000000000000000000000a KeyMR ef439af7b8bba0ecaf786f3d6b4b03977cbe1a5b66f413c1f3f7a7416ac998f4 } EntryBlock { ChainID 000000000000000000000000000000000000000000000000000000000000000c KeyMR 95e7dcec96787519676cfd3d2951b8740763a384736eafb87ffa40af170b9aa3 } EntryBlock { ChainID 000000000000000000000000000000000000000000000000000000000000000f KeyMR 810da0af022deb1474dfe640f4ec769f5c924a6b555a7378a6db5802d49cea29 } — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#496>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALGRx5aBbkqThi2kdwyoA7ZB-hro_uXPks5t72rvgaJpZM4Uj5b5> .

-- Thank you, D. Robert Baker

[jcheroske]

The timestamp returned by factom-cli get dblock is the standard Unix
timestamp in seconds.
The timestamp returned by factom-cli get dbheight is the Unix timestamp in
MINUTES.

The horror.

[OrmEmbaar]

That is rather confusing and not at all expected behaviour. I have never come across unix time represented in minutes, only seconds or milliseconds.

Is there a particular reason to represent unix time in minutes for get dbheight in particular? Surely it should at the very least be consistent.

[drobertbaker]

The resolution of the block is only in minutes, so at some point, someone felt that there was no need for a finer meaningless reporting.

…

On Tue, Jun 12, 2018 at 2:17 AM, AlexCarrithers ***@***.***> wrote: This call: factom-cli get dbheight 144378 Contains as part of the response: "dbhash": "6dcbd123507b51a386d16815b9159e7e68d6e383a756d123c916222ff452b8a8", "keymr": "d750bca37731519658303f40cbfbb7ab87fad240770fa8aea3af4770334faa86", "header": { "version": 0, "networkid": 4203931042, "bodymr": "63b9981e9d44ae0a3d36a23bed72cf423cf6ef956dd1b49814edc5eb57e2f03d", "prevkeymr": "70bdde669000bd1d67241448b3fd34f08dedc9f4627b03cef2b469528f7c945b", "prevfullhash": "0398c7cb74bc5c79ba3e1c976bdc5d50a467edf1e57c57e8a55ad8b8ec5b45a7", "timestamp": 25475055, "dbheight": 144378, "blockcount": 3, "chainid": "000000000000000000000000000000000000000000000000000000000000000d" }, If you look at the timestamp, 25475055 you'll see that it is for some date in late 1970. Conversely, if you call that block hash directly with: factom-cli get dblock 6dcbd123507b51a386d16815b9159e 7e68d6e383a756d123c916222ff452b8a8 Then it returns the correct time: PrevBlockKeyMR: 70bdde669000bd1d67241448b3fd34f08dedc9f4627b03cef2b469528f7c945b Timestamp: 1528503300 SequenceNumber: 144378 EntryBlock { ChainID 000000000000000000000000000000000000000000000000000000000000000a KeyMR ef439af7b8bba0ecaf786f3d6b4b03977cbe1a5b66f413c1f3f7a7416ac998f4 } EntryBlock { ChainID 000000000000000000000000000000000000000000000000000000000000000c KeyMR 95e7dcec96787519676cfd3d2951b8740763a384736eafb87ffa40af170b9aa3 } EntryBlock { ChainID 000000000000000000000000000000000000000000000000000000000000000f KeyMR 810da0af022deb1474dfe640f4ec769f5c924a6b555a7378a6db5802d49cea29 } — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#496>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALGRx5aBbkqThi2kdwyoA7ZB-hro_uXPks5t72rvgaJpZM4Uj5b5> .

-- Thank you, D. Robert Baker

[stackdump]

@jcheroske @afenrir this still on your wish-list?

[OrmEmbaar]

It is on my wish list for v3, though I recognise that we should not change this now. A consistent API improves clarity and speed of development.