I understood the C source of qtime, however, I didn't understand why you did your calculation that way. So, could you please explain it to me or point me to the original algorithm of your calculation.
You are seeing the original algorithm.
Back around 1990 there was a tiny closed-source commandline program for the Amiga named qt, written by one of the authors of the BBS frontend TrapDoor. I wrote my own implementation back then, in MC68k assembler. I was an self-taught amateur hobby programmer at that time, and I still am today.
I can't tell you now why I reasoned like I did 30 years ago. Is there something in particular that you find odd?
QTime is a 12 hour clock with a granularity of 1 minute. For every 5-minute interval, two divisions will be ‘to’ (‘nearly’ and ‘almost’), one will be on the spot and two will be ‘past’ (‘just after’ and ‘after’). So it's all about finding the right 5-minute interval in the right hour on a 12-hour clock and finally finding which of the 1-minute divisions we're gonna use within said 5-minute interval.
It is the adjustment of the minutes that is difficult to grasp for me. Why did you add 30 seconds and 27 minutes to convert the number of seconds obtained by the get_secs function to get the adjusted number of minutes?
At half past we still refer to the current hour, e.g., 12:30 is ‘half past twelve’. Because of the 1-minute granularity we then say ‘just after half past twelve’ (12:31) and ‘after half past twelve’ (12:32) before we switch to the next hour: 12:33 is ‘nearly twenty-five to one’. So in order to calculate the right hour we round up by adding 27.5 minutes to the actual minutes. This also gives us the right number of minutes, since our minutes only go from 0 (‘o'clock’) to 30 (‘half past’), not from 0 to 59.
I haven't thought it through, but perhaps you could achieve the same by adding half an hour and do a modulus 30, but 30 years ago my brains decided to use the algorithm you see.
Is 27.5 minutes coming from the fact that 55/2=27.5?
27.5 minutes is coming from the fact that it is what is remaining when you're halfway between HH:32 and HH:33: (60−(32+33)/2 == 27.5). I.e., at HH:32:30 you go from saying "It's after HH" to "It's nearly twenty-five to HH+1", so adding 27.5 minutes is like rounding up to the next pronounced hour (HH+1) the same way adding 0.5 to a decimal and then rounding to the nearest integer will round up arithmetically.
PS: And the reason we use 27.5 minutes to round up, and not 30 minutes, is that when we pronounce the time, HH:31 and HH:32 still belongs to "half past HH", so they shouldn't be rounded up to HH+1.
Thank you very much.
Your solution of the problem is succinct and clever. I studied the solution of the original program you mentioned earlier (maybe it is this one: https://ftp.fau.de/aminet/util/time/QTime.readme ), the solution was simpler but more lines of code.
Thanks for the link, I can see the author uses a completely different approach.
I'm pretty sure it is not the original qt program I had. The one I'm thinking of was written by Martin Laubach (who authored TrapDoor with Maximilian Hantsch).
I'm sure several people has implemented this. There was also a qt.rex REXX script included with the ooRexx distribution at one point.
Personally, I've found it's funnier to implement QTime whenever I try out a new programming language, than the usual "Hello, World!" program. I've also written implementations in Idris and Rebol, among others, but I no longer have the sources. My implementation in MC68k assembler is also gone, sadly.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?