`clock.LocalTime()` sets the location of a `time.Time` object, but
doesn't change the point in time. Since `clock.LocalTime()`
calls `time.Now()` to create the "local time", what ends up
happening is that the first `LocalTime()` is always "before" the
second one (because of the order of function calls), leading to
unstable sorting.
This change does two things to fix chronological sorting. The
first is to add a `clock.ToLocal(time.Time)` function that
acts like `clock.LocalTime()` for a given time point, so that
a single stable time point can be used throughout sorting. The
second is to do chronological sorting by comparing the string
versions of the local time, which look like (for London vs. SF):
2018-06-01 19:48:26.591550198 +0100 BST
vs.
2018-06-01 11:48:26.5915538 -0700 PDT
There may be a better way, this feels hacky-ish but works for me
on OSX.
One remaining downside is that for locations in the same time zone
(i.e. Avignon and Barcelona in the default settings), order is
determined ~randomly on startup. You could maybe append the location
to the string used for comparison to make alphabetical sorting a
fallback for equivalent times, but at least they don't jump around
anymore.
This is just a minor change to avoid a small number of inexperienced
users not be intimidated by a minor mistake, such as the incorrect
setting of the TERM environment variable.
I hope this will be improved a bit of user experience for let WTF
more popular.
`clock.LocalTime()` sets the location of a `time.Time` object, but
doesn't change the point in time. Since `clock.LocalTime()`
calls `time.Now()` to create the "local time", what ends up
happening is that the first `LocalTime()` is always "before" the
second one (because of the order of function calls), leading to
unstable sorting.
This change does two things to fix chronological sorting. The
first is to add a `clock.ToLocal(time.Time)` function that
acts like `clock.LocalTime()` for a given time point, so that
a single stable time point can be used throughout sorting. The
second is to do chronological sorting by comparing the string
versions of the local time, which look like (for London vs. SF):
2018-06-01 19:48:26.591550198 +0100 BST
vs.
2018-06-01 11:48:26.5915538 -0700 PDT
There may be a better way, this feels hacky-ish but works for me
on OSX.
One remaining downside is that for locations in the same time zone
(i.e. Avignon and Barcelona in the default settings), order is
determined ~randomly on startup. You could maybe append the location
to the string used for comparison to make alphabetical sorting a
fallback for equivalent times, but at least they don't jump around
anymore.
