I've been using the 'decimal day' informally for my own purposes for several years, and used to have a widget display it along with 'regular' time on my workstation. I tend to write it as 20191212.75, i.e., pretending that the year, month, and day represent an integer value; this works well for ordering, but of course is rather severely flawed for any other sorts of calculations. Since a day has 1440 minutes, 15 minutes can be very crudely used as 1/100 of a day, allowing fairly easy estimation of the current decimal time from a glance at a clock. I'm not sure why I like this; surely not (just) to annoy my mathematician son...
I used 'decimal years' in some systems as well, and thought that made a lot of sense, simplifying the storing of dates into a single value, and supporting both ordering and calculations, at least to a point. I'm not sure how either of these would work out in coreutils date(1), since it has to take a more formally correct approach, but perhaps they could be useful. Ken On Fri, Dec 13, 2019 at 1:57 AM za3k--- via GNU coreutils General Discussion <coreutils@gnu.org> wrote: > > I am interested in adding support for decimal time to 'date', but before > I dive into writing a patch, I wanted to ask whether the patch has a > chance of being accepted--this may just be too obscure. > > In decimal time, 2019-12-12.75 would represent 2019-12-12T18:00:00. > Decimal time in the modern era is mainly used in timekeeping (to track > employee or contracting hours) and in scientific recording (to make > drawing graphs easy). Astronomers use another form of decimal time on > their own calendar and would not be supported. > > --- > Some planned specifics > The calculation is straightforward: Divide the number of seconds elapsed > in the day by the total number of seconds in the day. > > Based on my research, anyone who cares about accuracy uses standard > time, so there is not an established standard on how to deal with DST > changes. My plan would be to divide by the correct total number of > seconds for leap seconds, and to throw an error if the locale has a DST > change on the day. > > The internal implementation width would be 14 digits (slightly more than > nanosecond accuracy). I would follow the convention set in %N that the > field truncates, rather than rounds, the decimal value. The default > printed width would be 5 digits (slightly more than second accuracy). > > I will not include parsing support, because of issues with rounding, and > potential confusion with standard date formats. > -- Ken Irving
