Better logging on Subql test failing on matching dates

[bz888]

Prerequisites

• Are you running the latest version(s)?
• Have you searched the documentation for your issue?
• Did you search for an existing issue or pull request?

Description

Subql-test failing despite having the same date logged, the test fails.
This is due to the difference in milliseconds-nanoseconds, but the log does not print that.
we should print this for clarity when failing a test due to this.

e.g.

expected time: 1708742045000 // Saturday, 24 February 2024 02:34:05
actual time 1708742045762 // Saturday, 24 February 2024 02:34:05.762

The fail log should show the difference between these date values.

Details

These details can help to reproduce the environment the issue is occurring

Local Environment: [You can get this information from executing subql version.]
Query Version: [What is the version of the query service?]
Indexer Version: [What is the version of the indexer service?]
Network Details:

• [Network]
• [Block height, a block height where the issue is happening]
• [Dictionary endpoint, if used]

Steps to Reproduce

1. [First Step]
2. [Second Step]
3. [and so on...]

Example project: [A link to a minimal example that can reproduce the issue]

Expected behavior: [What you expected to happen]

Actual behavior: [What actually happened]

Any other information

Is there any other information you would like to add?

[apollo-sturdy]

Any update on this? Would be great to get this fixed.

[stwiname]

@apollo-sturdy this is low priority for us right now.

You're more than welcome to make a PR that fixes the issue

[apollo-sturdy]

@apollo-sturdy this is low priority for us right now.

You're more than welcome to make a PR that fixes the issue

I ended up switching to using unix timestamps to avoid the issue. Do you know what the max value for the Int type is? I couldn't find it in the docs. Asking cause I'm unsure if I need to use BigInt for unix timestamps in milliseconds.

[stwiname]

@apollo-sturdy this is low priority for us right now.
You're more than welcome to make a PR that fixes the issue

I ended up switching to using unix timestamps to avoid the issue. Do you know what the max value for the Int type is? I couldn't find it in the docs. Asking cause I'm unsure if I need to use BigInt for unix timestamps in milliseconds.

Int should be more than enough for unix timestamps in milliseconds