12-Hour Time

[machineghost]

12-hour time is a standard in every (American) application, but Hamster Time Tracker only does 24-hour time. This makes my lazy American brain hurt! ;)

Please add a preference for switching to 12-hour time.

[ederag]

That would change the fields widths and above all, add more constraints to the parser.
The parser was already quite a piece to improve and stabilize for v3.0.
Let's reevaluate later, with the timezone fix (#155) that will touch the same code part.

[machineghost]

It's your project, so you should do what you gotta do and not listen to anyone who says otherwise.

And to be 100% honest, I barely even use the app anymore. But my personal opinion is ...

.. when you start trying to justify not doing something that is purely visual, has nothing to do with parsing, and would clearly make your app better (for non-military users at least) ...

... by blaming it on parsing and/or on the inability to change a few characters of text into a few other characters of text (which is literally all we're talking about: "13:05" => "1:05PM") ...

... it'd be more honest to just say "I don't want to do this".

[ederag]

Please tone down.
Think that you are addressing people working for free on their free time,
and not obliged to in any way.
No wonder this project went so long without any maintainer.

For instance a correct way to ask would be
"Could you indicate why you relate this choice with the parser ?" or even just
"Why did you relate this choice with the parser ?"
Rather than accusing of being sneaky (not my style):

it'd be more honest to just say "I don't want to do this".

And it's not "my" project, it's more our predecessor's,
and as its maintainer, I like to take feedback, to take better decisions.

---

Here is the train of thoughts that was missing in my post:
Once people see am/pm, they will want that in the parser,
and be frustrated by the discrepancy between the display and the parser.
That would be worse than the current clear rule: only 24h.

[machineghost]

As I tried very hard to stress (yet somehow it was lost), I was not attacking you. It's entirely your project, and as a person working for free on their free time on that project, you should do ...or not do anything you want.

But whatever your motivations, when you say "I won't fix this thing because I can't make some text change", it comes across as disingenuous. Your later post clarified, so now I'll stop saying anything to avoid antagonizing you further.

[ederag]

No hard feelings, for an outsider, a crucial part was indeed missing in my post, as said above.
And it was natural to take it as a dismissal in disguise.
Yet it was wrong in this particular case; the intention really was to reevaluate later.

The 24h system has many advantages, and it will be a relief in the long run,
but we are still transitioning in France
(most displays are 24h, but informal talk is often 12h when context is clear),
so I do sympathize (to be clear, 24h is now more than fine with me, but I do remember the effort).

---

Many people assume that a maintainer not using a feature do not care,
Except that's not the way many maintainers work
(they would do something else if they were purely selfish, frankly).
For instance the extension I never use is fully supported:
#548
#562
The wayland fix took even more time:
had to set up a virtualbox, read a lot of old cruft online, face a dead-end due to a Gtk.Entry limitation,
before finding out the correct simple way: #527
and I'm on xorg, not wayland.
I cared for gnome integration while being on kde, etc.

---

As far as parsing is concerned, the most worrying aspect of 12h is
the space between the time and "am/pm", that seems standard:
https://www.timeanddate.com/time/am-and-pm.html
https://writingexplained.org/am-or-a-m-pm-or-p-m-do-i-capitalize-am-and-pm
https://en.wikipedia.org/wiki/12-hour_clock

12h people will want the space, asking for 9:00pm will not do.
They'd be frustrated to no end when they'll type naturally 9:00 pm what
and see that the activity is pm what and the time is 9:00 in the morning.
So space there must be.
But that would prevent the entry of any activity starting with am or pm, e.g. am pause
(the ante-meridian coffee break), and frustrate another set of users.

Branching the parser with a "12h/24h" option is possible in principle,
but that would increase reasoning and testing a lot, see the first comments to #465.
It would be tempting to branch "only for this problem",
as the parser is cleaner, it might seem doable.
But that would be shortsighted, IMO.
There were many other parser difficulties that could have been solved with yet another option.
The parser is both more powerful and cleaner precisely thanks to their advise.

Every feature has to be balanced with maintenance cost.

Let's reevaluate whether there is a smart way to achieve 12h or not,
when thinking about the parser again for #155.

[machineghost]

That all sounds good except:

As far as parsing is concerned, the most worrying aspect of 12h is
the space between the time and "am/pm", that seems standard:
https://www.timeanddate.com/time/am-and-pm.html
https://writingexplained.org/am-or-a-m-pm-or-p-m-do-i-capitalize-am-and-pm
https://en.wikipedia.org/wiki/12-hour_clock

12h people will want the space, asking for 9:00pm will not do.
They'd be frustrated to no end when they'll type naturally 9:00 pm what
and see that the activity is pm what and the time is 9:00 in the morning.
So space there must be.

As someone who has lived in a 12 hour country (America) my entire life, you have a mistaken impression as an outsider. That space is not in any way required.

I will say that having the space is probably more common than not, and I think it's more conventional to use lowercase letters if you don't have the space, ie. 9:00am or 9:00 AM looks more normal than 9:00AM or 9:00 am.

But really, we're used to seeing 12 hour time displayed on lots of devices in lots of ways, and it's not at all like there's only one standard way of doing that.

[ederag]

Interesting, so lower case without space it could be.

we're used to seeing 12 hour time displayed on lots of devices in lots of ways

Display is not a big concern.
It's more about input.

Would you say that by seeing 9:00am (lower case, no space) everywhere in the application,
users would instinctively always input without a space ?
That would be a game changer.

I will say that having the space is probably more common than not.

That's what the links given show, indeed.
So the question is how many would still type 9:00 AM (with a space) and be hurt.
My experience as a maintainer is that users tend to be highly frustrated
by that kind of non-intuitive behavior.
Then we are back to the last part of my previous comment.

Granted, others are frustrated by the 24h only, that counts !

I'd leave this open as a poll, to evaluate balance,
and for further ideas.
We are in a transition; I couldn't stay maintainer here.

[machineghost]

I'm not sure I even understand the problem. On the input side, who cares if they input "9:00 am" or "9:00am", because eliminating the space from the input should be trivial, no?

I'm not sure what language you're using, but I mean a regex replace should do the trick in only a single line in any language.

[ederag]

As said above, it's not a regex issue (that's trivial), it's a matter of logic,
and a counter-example has been given in
#359 (comment)
You are looking at a very small subset of all that must be parsed. That's why you think it is simple.
It's just that you don't know the code, and do not have an idea of all the tests that must pass.

Here if you eliminate the space, how do you parse 10:00 am pause
without knowing if it's 12h (pause at 10 AM) or 24h (am pause: ante-meridian pause at 10:00)
Then search for "branch" above. See ?
It's always simpler for users than for maintainers. It's natural, but please keep that in mind.

[machineghost]

I think there are issues in any UI that tries to use a single textbox to enter such vastly different things as "10:00 am pause" and "10:00 24 hour time with a special kind of pause called an AM pause". One textbox can only do so much: at some point you need to introduce more UI (eg. a couple of radio buttons for 12/24 hour time).

If you don't want to do that right now I can understand that, but I just think your core problem is expecting a single textbox to do so much. Sure it can, but we have other controls for a reason.

[mwilck]

@machineghost, there has been quite a bit of discussion about this in various hamster issues lately. @ederag has actually done something similar in #461 (though without an 12/24h radio button, so far).

The point is that the single text entry field is one of hamster's strongest assets, at least for me. I believe that time tracking should go out of the user's way, and thus the input should be as simple as possible. Clicking through half a dozen UI inputs in order to create a single entry should be the exception, not the rule.

We do have the "separate input fields" in 3.0, but past discussions led to the agreement that every input that can be done with multiple UI controls should also be doable with the single text entry field. See #481 and links therein.

As you noted correctly, this comes necessarily with a few restrictions. Forbidding a space before "am" or "pm" seems to be a pretty gentle restriction to me. I'm sure you'll have little trouble getting used to it.

In general, there's no shortage of special wishes from users, see e.g. #423, #280. The common denominator is that every user (I'm no exception) regards his own preference as the common case. #465 has a number of examples for possible "pathological" input, and illustrates nicely how different people's expectations wrt the parser may be, even if they're all long time hamster users.

@ederag has spent a lot of effort to accommodate these wishes while maintaining single-text-entry compatibility. It's a non-trivial task, the "fact" entry may contain time, date, activity, category, description, and tag fields, except for "activity" they are all optional, and some fields may contain whitespace. We must maintain backwards compatibility, and keep the parsing rules simple enough that people can remember them (what you want least is having to open the help page for every 2nd activity you enter). I believe that @ederag has done a pretty good job on this almost unsolveable task.

[machineghost]

I think the summation of this is, "you can't make all the people happy all the time" :-) Different users just have different needs. To some (I'd hazard a guess of the majority, but obviously I'm biased) a single input in a UI being "overloaded" with many functions is a detriment, but to others it's absolutely a positive.

This isn't the timer for me, but that doesn't mean it won't serve a certain set of people's needs. The only unfortunate thing is that it feels like Linux is full of niche timers.

UI design is not a new problem. Trust me, there's no arguments at companies like Facebook or Google over whether you should overload an input for time, nor will you find UI experts from either company (or any other) disagreeing with each other (on the basics of time UI I mean; I'm sure they have arguments over specific details).

Major user-focused companies have entire standards on how to build clock UIs, based heavily on usability research ... which in turn is based on people's experiences with many other UI's: we all leverage our past experience with clock UIs that we've seen ... or any UI ... when we use a new UI.

It feels like Linux devs in general are less interested in trying to leverage that vast body of usability knowledge. But at the same time, I completely understand the burden of maintaining OSS software (and respect you and similar devs for shouldering it), so I'm not faulting you in any way. I'm just saying "if you have time, maybe look at how people (who have way more time to spend on solving these problems) have solved them ... or don't, and keep serving the users you serve!"

[mwilck]

@machineghost,

if you can recommend a specific, exemplary UI, the hamster community would certainly be interested. It's true and widely ack'd in the community at large that developers are not the ideal UI designers.

That said, I don't think anyone will program a "dial"-style time input like Google Calendar anytime soon. Moreover, I believe that a time keeping application like hamster has different UI needs than e.g. a calendaring application, and that an UI for Linux (where the keyboard is still the primary input device for many users) would be different from a mobile UI.

I agree that hamster is currently trying to do "too much", but have no idea where to start if we want to do "less" - whatever we do, we'd hurt some users. If the project really re-gains considerably more momentum, we'll need to have an open discussion about this, and this discussion will need to take examples of other, possibly better UIs into account. Part of the problem is that OSS development works in small steps (fix a bug here, add a small feature there), and that model doesn't work well for UI design, where you need to create the "big picture" first.

[ederag]

It's true and widely ack'd in the community at large that developers are not the ideal UI designers.

Except @tstriker, he's a UI master, in my opinion.
He has proved both a great dev and an amazing UI designer,
hence the success of hamster.

@mwilck You were probably talking generally, and in general you are true,
I just took the opportunity to express thanks again 🙂.
Hopefully no one will try to start an argument (talking for passers-by, I know you won't).
That would be trolling shame in this context, and I will not answer any.