In a project where I had to compile data about the average times certain operations took, I used the since and math functions as suggested here:
Specifically I wanted to divide nodes into groups based on the amount of time between two datetime values on that node. Typically this difference would be 2-15 minutes and I wanted to separate the nodes into 5 minute increments.
This seemed to work fine, but after making several of these reports I realised that the exact same report had different numbers of nodes per group, depending on when I made the report. The fluctuations varied apparently randomly, and in theory the difference should be set in stone. The variability increased as I went further back in time (so the separation was more accurate for times that were set yesterday, but much more inaccurate for times set last year)
I can only assume it’s a floating point issue, seeing as since is a floating point number of the number of seconds since the datetime in question. So as time goes on, these errors will only increase. For my type of application this is totally unacceptable.
My solutions are:
- Do not use dgraph datetime variable type, and instead save datetimes as the value of miliseconds since Jan 1st 1970 (is this not how they are represented internally anyway?). This allows me to use all the Math functions on the values in an accurate way.
- Do any such operations in the client (not useful if I want to combine sorting and pagination on these derived values).
I could envisage a system that uses no dateTime variables at all and only stores them as integers, but it would make readability worse.
Any thoughts? Has anybody else come across this issue and found a better solution?