Skip to content

Reimplement #1652 - switchable time formats#1985

Merged
daschuer merged 24 commits intomixxxdj:masterfrom
daschuer:hectoseconds
Jan 27, 2019
Merged

Reimplement #1652 - switchable time formats#1985
daschuer merged 24 commits intomixxxdj:masterfrom
daschuer:hectoseconds

Conversation

@daschuer
Copy link
Copy Markdown
Member

@daschuer daschuer commented Jan 6, 2019

This is a rebased Version of #1915 onto the original #1652
to keep the original commit messages.

@daschuer
Copy link
Copy Markdown
Member Author

daschuer commented Jan 6, 2019

LGTM, waiting for CI

Comment thread src/util/duration.cpp
@benis
Copy link
Copy Markdown
Contributor

benis commented Jan 7, 2019

There is still some work to do on this. Is there a way for me to push to this PR?

Also, the tests you said were failing - how do you run those?

@daschuer
Copy link
Copy Markdown
Member Author

daschuer commented Jan 7, 2019

You can issue a new pull request against this branch in my daschuer/mixxx repro.
Or you issue your own pr and we close this.

You can run the test on Linux by starting
./mixxx-test

The verify debug assert was wrong because we use it only for conditions that never happens. But it happens at least during the test. I am not sure if it happens during Mixxx with faulty tracks for example.

@daschuer
Copy link
Copy Markdown
Member Author

daschuer commented Jan 7, 2019

You can get this by:
git checkout -b hectoseconds2 upstream/master
git pull https://github.com/daschuer/mixxx.git hectoseconds

@daschuer
Copy link
Copy Markdown
Member Author

@benis: Is it possible to finish this by the end of January?
I like to see this in Mixxx 2.3. Or can we merge this step as it is?
Which changes do you have planned?

@benis
Copy link
Copy Markdown
Contributor

benis commented Jan 10, 2019

I would hope to have this done by the end of January for sure.

I've just created a PR to your hectoseconds branch with the change for Traditional (Coarse) time format.

@benis
Copy link
Copy Markdown
Contributor

benis commented Jan 10, 2019

I still need to check if the tests are working and figure out why not if not. If you can merge the PR I made to your hectoseconds branch, the tests are the only critical thing before this could be merged.

Here are some other things I would like to look at:

  • Can we find a more conventional choice of separator character?

Also, the options displayed in the Deck Preferences are a bit inconsistent:
screenshot 2019-01-10 at 21 25 10

  • is there a way to indicate that the hh is optional, or could we just remove it? Not many tracks over an hour long.
  • 's zz' uses the defined centisecond separator character (thin space) - should it?
  • 'k.sss zz' uses a static period, even though the actually-displayed character might be different. Then the defined centisecond separator character is used between sss and zz
  • 'hs.ss zz' also has a static period but uses the hectosecond separator character between ss and zz
    (See dlgprefdeck.cpp:122 onwards for relevant code.)

I also noticed that if you choose a different time format in Preferences but then hit Cancel, when you next load Preferences the drop-down has retained your value, so if you go back in to change something else, the deck preferences then get applied too.

@benis
Copy link
Copy Markdown
Contributor

benis commented Jan 10, 2019

Just ran the tests, if I've understood the output correctly they now pass.

@daschuer
Copy link
Copy Markdown
Member Author

Formating:
Let's follow strictly the SI recommendation in en-US format.
Decimal separator .
Thouthands colon ,
Decimal places seperator thin space.

Seconds ss,sss.ss
Kiloseconds ss.sss ss
Hectoseconds sss.ss ss

For the hh: I think a minute only format is also common. A movie runtime is given as 98 min for example. So we can pick IMHO that and drop the hh: entirely.

@benis
Copy link
Copy Markdown
Contributor

benis commented Jan 11, 2019

I don't think your examples match up with SI. The SI standard says that decimal places can be separated by a point or a comma (the former in US), and that the thousand separator should be a space. That makes sense to me, could we also use it as the hundred separator in the hectoseconds format?

The choice of variable names for separator characters (both 'group'
separator characters and decimal separator), as well as the actual
application of formatting, was inconsistent and confusing. Now it's
better, hopefully.
@benis
Copy link
Copy Markdown
Contributor

benis commented Jan 13, 2019

Traditional OK

Traditional (Coarse) OK

Seconds OK

Kiloseconds NOK

* This is part of a kiloseconds movement https://kilosecond.info/ the

* I think it should be 0.000 62  -1.000 95

Hectoseconds I don't care much

* I think it should be 0.00 62  -10.00 95 according to SI.

I still don't think that's consistent with SI, but feel free to change it.

@daschuer
Copy link
Copy Markdown
Member Author

I still don't think that's consistent with SI, but feel free to change it

I can do this. Why do you think my proposal is not SI?
IMHO the decimal point needs to shifted with kilo and hecto.

@benis
Copy link
Copy Markdown
Contributor

benis commented Jan 14, 2019

https://en.wikipedia.org/wiki/International_System_of_Units#General_rules

  • The symbol for the decimal marker is either a point or comma on the line
    ...
  • Spaces should be used as a thousands separator (1 000 000) in contrast to commas or periods (1,000,000 or 1.000.000) to reduce confusion resulting from the variation between these forms in different countries.

So spaces for thousands, point or comma for decimal marker. You're proposing to do the opposite.

Comment thread src/util/duration.h
class DurationBase {

public:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I seem to have introduced this empty line in error.

@daschuer
Copy link
Copy Markdown
Member Author

So spaces for thousands, point or comma for decimal marker. You're proposing to do the opposite.

I read this like this:
1 ks = 16 min + 40 s
1 000 ks = 11 d + 13 h + 64 min + 40 s
0.9 ks = 15 min
0.001 ks = 1 s
0.000 001 hs = 1 ms

1 hs = 1 min + 40 s
1 000 hs = 27 h + 46 min + 40 s
0.9 hs = 1.5 min
0.001 hs = 100 ms
0.000 01 hs = 1 ms

@benis
Copy link
Copy Markdown
Contributor

benis commented Jan 19, 2019

Ah, I see where you're coming from now, sorry for the confusion. Are you happy to change it? It will be less faff than me submitting another PR to you.

@daschuer
Copy link
Copy Markdown
Member Author

OK I will do the change, I am only unsure about hecto seconds.
should we go with the SI correct:
0.000 1 hs = 10 ms
with the nicer looking:
0.00 01 hs = 10 ms

@benis
Copy link
Copy Markdown
Contributor

benis commented Jan 19, 2019

I vote for the second one. It's kind of an unconventional format so why not.

@daschuer
Copy link
Copy Markdown
Member Author

OK, done.

However, I have just played with it and it feels odd.
I am considering to replace it with a plain seconds format with three leading zeros.
000.00

Or should we reintroduce your original hectoseconds format?
What do you think?

@benis
Copy link
Copy Markdown
Contributor

benis commented Jan 19, 2019

I'm not attached to the hectoseconds format, so I wouldn't mind if we replaced it. I think your suggestion is a better choice and more likely to get used.

@daschuer
Copy link
Copy Markdown
Member Author

OK I will change it.

…o hard to read and the new long format is basically the same but with other separators
@daschuer
Copy link
Copy Markdown
Member Author

Done. What else is missing before merge?

@benis
Copy link
Copy Markdown
Contributor

benis commented Jan 20, 2019

I think that's everything. I inadvertently introduced a blank line in src/util/duration.h (:17) so I guess this would be a good time to fix that, but otherwise this is good to go.

@daschuer
Copy link
Copy Markdown
Member Author

OK, I am fine with this now.
We may consider to alter also the library column accordingly, but that is a separate PR.

@uklotzde Is anything left to do before merge?

@daschuer
Copy link
Copy Markdown
Member Author

OK time to merge this.

@daschuer
Copy link
Copy Markdown
Member Author

Thank you @benis and @poelzi for working on this.

@uklotzde
Copy link
Copy Markdown
Contributor

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