Incorrect timestamp returned from view

[skenaja]

Description
Wrong timestamp is returned from simulating onchain view of a contract. Looks like it might be a date conversion issue

Tested with v13.0.0 and v19.0.0

Steps To Reproduce

const { TezosToolkit } = require('@taquito/taquito'); 

const Tezos = new TezosToolkit('https://mainnet.ecadinfra.com/');

const contractAddress = 'KT1ExbCyFbsvPQTUitHAK7HSfYkJgiCtBGpM';
const caller = 'KT1JdufSdfg3WyxWJcCRNsBFV9V3x9TQBkJ2';

Tezos.contract.at(contractAddress)
  .then ((contract) => {
    return contract.contractViews.get_price_with_timestamp("XTZUSDT").getSignature()
  })
  .then((signature) => {
    console.log(`The signature of the view is:`);
    console.dir(signature, { depth: null })}
  )
  .catch((error) => console.log(`Error: ${error}`));

Tezos.contract.at(contractAddress)
  .then((contract) => {
    return contract.contractViews.get_price_with_timestamp("XTZUSDT").executeView({ viewCaller: caller })
      .then((viewResult) => {
        console.log(`The result of the view simulation is:`);
        console.dir(viewResult, { depth: null });
      })
  })
  .catch((error) => console.log(`Error: ${error}`));

Actual behavior

The signature of the view is:
{
  parameter: 'string',
  result: { price: 'nat', last_update_timestamp: 'timestamp' }
}
The result of the view simulation is:
{
  price: BigNumber { s: 1, e: 6, c: [ 1649000 ] },
  last_update_timestamp: '+056901-10-22T12:19:50.000Z'
}

Expected behavior

{
  parameter: 'string',
  result: { price: 'nat', last_update_timestamp: 'timestamp' }
}
The result of the view simulation is:
{
  price: BigNumber { s: 1, e: 6, c: [ 1650150 ] },
  last_update_timestamp: '2024-12-06T10:19:56Z'
}

[skenaja]

Maybe I'm missing something obvious - the timestamp in the contract storage also comes back in this same format

Tezos.contract.at(contractAddress)
    .then((contract) => {
      return contract.storage();
    })
    .then((storage) => {
      return storage['prices'].getMultipleValues(["XTZUSDT"]);
    })
    .then((result) => {
      console.dir(result, { depth: null });
    })
    .catch((error) => console.log(`Error: ${error}`));

MichelsonMap {
  valueMap: Map(1) {
    '"XTZUSDT"' => {
      price: BigNumber { s: 1, e: 6, c: [ 1656850 ] },
      last_update_timestamp: '+056901-11-16T12:16:27.000Z'
    }
  },
  keyMap: Map(1) { '"XTZUSDT"' => 'XTZUSDT' },
  [Symbol(taquito-michelson-map-type-symbol)]: true
}

[skenaja]

found a hacky workaround to convert this to the correct js Date:

console.log('date: ', new Date( Math.floor(new Date("+056901-11-16T12:16:27.000Z").getTime() / 1000) ) );
date:  2024-12-06T10:55:56.187Z

[roxaneletourneau]

@skenaja Thank you for submitting the detailed issue.
It appears that the timestamps in this contract are stored in Unix milliseconds. However, timestamps are expected to be in Unix seconds according to Tezos documentation:

The timestamp type represents the number of seconds since January 1st, 1970, also known as UNIX time.

In Taquito, we currently only support Unix timestamps in seconds. This explains why your workaround works, as you are converting from milliseconds to seconds.

We need to investigate why it was possible to save Unix timestamps in milliseconds to the blockchain and whether we need to support both formats in Taquito.

[skenaja]

thanks makes sense! BCD shows the expected timestamp, and it turns out they were supporting milliseconds https://better-call.dev/mainnet/KT1ExbCyFbsvPQTUitHAK7HSfYkJgiCtBGpM/storage/big_map/597699/keys

https://github.com/baking-bad/bcdhub/blob/a9dd475f3d5dde5c1b438a5548531e8fd3c54bcb/internal/bcd/ast/timestamp.go#L58

[hui-an-yang]

i've posted this issue in tezos-dev michelson channel for some answers to assess if it makes sense to support both in taquito. https://tezos-dev.slack.com/archives/C69RKF3PG/p1733855975614059
Will get back to you when we hear back and the decision

[rafoo]

I can confirm that the timestamp Michelson type is only meant to store second-precision timestamps. Using it to store millisecond-precision timestamps can lead to hard-to-debug errors. In particular, I suspect that the get_price view on the same contract (https://better-call.dev/mainnet/KT1ExbCyFbsvPQTUitHAK7HSfYkJgiCtBGpM/views) always fail with the 386 error code because of this; it compares the second-precision result of the NOW instruction with the stored millisecond-precision timestamp which is thus interpreted as a timestamp in the far future and it fails because it expects all stored timestamps to be in the past.