You "have to make a clock where the minutes and seconds should not be above 60."
What does that actually *mean*?
The *second* part of a UTC time can be 60.
The *minute* part cannot.
So the limits for minutes and seconds should be different.
But what does "should not be above" mean?
One approach, given h, m, s is
m := s // 60 + m.
s := s \\ 60.
h := m // 60 + h.
m := m \\ 60.
h := h \\ 24.
In that approach, the interpretation of (h,m,s) is
- start with midnight
- add h hours m minutes and s seconds of duration
Another approach is
(s between: 0 and: 60) ifFalse: [s error: 'out of range'].
(m between: 0 and: 59) ifFalse: [m error: 'out of range'].
(h between: 0 and: 23) ifFalse: [h error: 'out of range'].
-- which completely fails to check that s, m, and h are
integers. We really want a version of #between:and: that
checks that the receiver and arguments are integers.
The first approach gets valid leap seconds wrong.
The second approach quietly accepts invalid leap seconds.
Currently, leap seconds can only occur on December 31 or
June 30. And you have to rely on tables to know *which*
years have which leap seconds. There is a proleptic
formula you can use to fill in leap seconds for years in
the past before there was such a thing as leap seconds,
but it doesn't help to predict future leap seconds.
Let's face it, leap seconds are a major pain in the posterior.
Not having leap seconds would also be a pain in the posterior,
but different posteriors are involved.
Is there a class in the Kernel/Chronology category that
might be useful to you?
What is the exercise you are trying to work on?
Locked
