Re: Decimal time support in 'date'

[Kenneth Irving]

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 <address@hidden> 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