Eos: get_scheduled_transactions returns expired transactions

[fproulx-dfuse]

RPC endpoint get_scheduled_transactions returns transactions that have expired long ago...

Is this normal? If so when do those get purged from memory?

$ curl https://mainnet.eoscanada.com/v1/chain/get_scheduled_transactions --data '{"json":"true","limit":10,"lower_bound":"2050-01-01T00:00:00"}' | jq -r .transactions[].expiration | sort

2066-01-26T14:41:23.000
2069-11-03T20:29:52.500
2018-07-31T03:34:00.500
2018-07-31T03:55:00.000
2018-08-04T19:04:00.500
2018-08-18T10:38:00.000
2018-08-18T10:38:00.000
2018-08-23T12:10:11.000
2018-08-23T12:10:11.000
2018-08-24T11:57:29.500

[wanderingbort]

As it turns out, they haven't expired long ago. They in fact wont expire for quite some time and this is an artifact of some bad narrowing on integers.

The raw form (which is 64bit signed microseconds from epoch) of these timestamps is:

5827975336500000
5827976596000000
5828376736500000
5829555976000000
5829555976000000
5829993507000000
5829993507000000

In order to convert these to ISO strings, we first call uint32_t time_point::sec_since_epoch()const as you would guess, this will divide the value by 1,000,000 to get seconds however it returns an unsigned 32bit integer. Each of the above values, when divided by 1,000,000 is not representable in 32bits (33rd bit is 1). as a result of the narrowing cast to 32bits, we end up with a bad number of seconds and therefore a bad string representation of the timestamp.

We should fix this faulty conversion