Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[util] Fix an issue with xtime.UnixNano.Truncate #3677

Merged
merged 7 commits into from
Aug 24, 2021

Conversation

arnikola
Copy link
Collaborator

This was previously not correctly following truncation as in time.Time,
since time.Time truncation calculates truncation duration from the date
January 1, year 1, 00:00:00.000000000 UTC, rather than epoch.

This was previously not correctly following truncation as in time.Time,
since time.Time truncation calculates truncation duration from the date
January 1, year 1, 00:00:00.000000000 UTC, rather than epoch.
@@ -94,12 +124,13 @@ func (u UnixNano) IsZero() bool {
// String returns the time formatted using the format string
// "2006-01-02 15:04:05.999999999 -0700 MST"
func (u UnixNano) String() string {
// return fmt.Sprint(u.ToTime().UTC().UnixNano())
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove

@@ -31,7 +31,7 @@ const (

// Now returns the current local time.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this comment still correct? doesn't seem to be local time anymore

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops yeah the comment is correct, should have reverted this change

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the comment is not correct, either. There is no notion of time zone on unix timestamp.
This ToUnixNano uses go time.UnixNano() under the hood, and see the end of it's comment:

// UnixNano returns t as a Unix time, the number of nanoseconds elapsed
// since January 1, 1970 UTC. The result is undefined if the Unix time
// in nanoseconds cannot be represented by an int64 (a date before the year
// 1678 or after 2262). Note that this means the result of calling UnixNano
// on the zero Time is undefined. The result does not depend on the
// location associated with t.
func (t Time) UnixNano() int64 {
	return (t.unixSec())*1e9 + int64(t.nsec())
}

So I would change our comment to something more formally correct like "// Now returns the current Unix time."

// NB:Number of seconds from epoch to timeZero.
unixToInternal int64 = (1969*365 + 1969/4 - 1969/100 + 1969/400) * secondsPerDay
)

// Truncate returns the result of rounding u down to a multiple of d.
// If d <= 0, Truncate returns u unchanged.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

update comment to be d <= 1

@arnikola arnikola requested a review from linasm August 20, 2021 17:33
@codecov
Copy link

codecov bot commented Aug 20, 2021

Codecov Report

Merging #3677 (0df1e39) into master (0df1e39) will not change coverage.
The diff coverage is n/a.

❗ Current head 0df1e39 differs from pull request most recent head baf4a31. Consider uploading reports for the commit baf4a31 to get more accurate results

Impacted file tree graph

@@          Coverage Diff           @@
##           master   #3677   +/-   ##
======================================
  Coverage    56.6%   56.6%           
======================================
  Files         551     551           
  Lines       61909   61909           
======================================
  Hits        35089   35089           
  Misses      23664   23664           
  Partials     3156    3156           
Flag Coverage Δ
aggregator 61.4% <0.0%> (ø)
cluster ∅ <0.0%> (∅)
collector 58.4% <0.0%> (ø)
dbnode 60.6% <0.0%> (ø)
m3em 46.4% <0.0%> (ø)
metrics 19.7% <0.0%> (ø)
msg 74.2% <0.0%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.


Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0df1e39...baf4a31. Read the comment docs.


func TestTruncate(t *testing.T) {
var (
n = time.Now().UTC()
Copy link
Collaborator

@robskillington robskillington Aug 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Perhaps best to set this to a static date? I wonder if it would flake if it's always "now".

Also maybe a few different "nows" should be tested that they all truncate properly, i.e. run tests on a few of them against all block sizes.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have any way of marking a flake as not a flake 😛 ? If this flakes then it implies there's still some underlying problem with truncation, would be useful to fail out if at all possible

Copy link
Collaborator

@linasm linasm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM just suggest fixing one existing comment to reduce confusion.

@@ -99,7 +129,7 @@ func (u UnixNano) String() string {

// Format returns the string representation for the time with the given format.
func (u UnixNano) Format(blockTimeFormat string) string {
return u.ToTime().Format(blockTimeFormat)
return u.ToTime().UTC().Format(blockTimeFormat)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't .UTC() conversion happen inside u.ToTime()?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call 👍

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@arnikola what was the reason to move .UTC() out of the UnixNano.ToTime() again before the merge?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was causing problems with failing tests elsewhere; I'll put out a followup that will since they merit further investigation to double check it's the tests that need updating rather than the code

@@ -31,7 +31,7 @@ const (

// Now returns the current local time.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the comment is not correct, either. There is no notion of time zone on unix timestamp.
This ToUnixNano uses go time.UnixNano() under the hood, and see the end of it's comment:

// UnixNano returns t as a Unix time, the number of nanoseconds elapsed
// since January 1, 1970 UTC. The result is undefined if the Unix time
// in nanoseconds cannot be represented by an int64 (a date before the year
// 1678 or after 2262). Note that this means the result of calling UnixNano
// on the zero Time is undefined. The result does not depend on the
// location associated with t.
func (t Time) UnixNano() int64 {
	return (t.unixSec())*1e9 + int64(t.nsec())
}

So I would change our comment to something more formally correct like "// Now returns the current Unix time."

Copy link
Collaborator

@linasm linasm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@linasm
Copy link
Collaborator

linasm commented Aug 24, 2021

@arnikola can we land this?

@arnikola arnikola merged commit fbb98ba into master Aug 24, 2021
@arnikola arnikola deleted the arnikola/time-truncate branch August 24, 2021 14:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants