Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upmake timestamp() return float64 #266
Conversation
This changes the return type of the built-in timestamp() function to float64 instead of int64. The unit remains the same, that is seconds since the Unix epoch. Before this change, timestamps were truncated to integer seconds, which made it impossible to measure durations less than a second. Unix seconds as a float64 give better than microsecond resolution. Fixes #263
|
I couldn't figure out how to declare in the golden format that a metric that has no value is a float. |
|
I appreciate you taking the time to make the PR but I think changing time from int to float isn't the right fix; I think it something that looks like time.Time should be exposed in the mtail language. |
|
Yes, I understand. This PR was more to just open the discussion and experiment what the minimal change that timestamp() returned a float would look like, and to see how backwards compatible it is. And it actually quite does work. Existing programs automatically get improved resolution, and even the tests suite mostly passes (couldn't figure out how to articulate that a metric is a float in the test result "golden" format.) It clearly would be more elegant if there was a Time type, but I don't see how that could be backwards compatible with existing mtail programs in case that is a requirement. Perhaps by making a timestamp2() function that returns the new type? If there is a Time type, it might also benefit from a Duration/Interval type as there is in Go, if we want to distinguish between calendar time and intervals using type safety. Or, perhaps nanotimestamp() function, that is like timestamp() but returns nanoseconds since epoch instead of seconds, could be an acceptable stopgap for new programs that require higher resolution? |
This changes the return type of the built-in timestamp() function to
float64 instead of int64. The unit remains the same, that is seconds
since the Unix epoch. Before this change, timestamps were truncated to
integer seconds, which made it impossible to measure durations less than
a second. Unix seconds as a float64 give better than microsecond
resolution.
Fixes #263