[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Decimal time support in 'date'
From: |
Kenneth Irving |
Subject: |
Re: Decimal time support in 'date' |
Date: |
Fri, 13 Dec 2019 05:53:34 +0000 |
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