GNU bug report logs - #20199
Enhancement request for date's "-d" option: different epochs

Previous Next

To reply to this bug, email your comments to 20199 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Ulrich Windl" <Ulrich.Windl <at> rz.uni-regensburg.de>
To: <bug-coreutils <at> gnu.org>
Subject: Enhancement request for date's "-d" option: different epochs
Date: Wed, 25 Mar 2015 13:26:25 +0100

Hi!

I'm not subscribed to this list, and I hope this is the right place to report an enhancement request as there seems to be no bugzilla for that.
Anyway: When downloading the current leap seconds list for out NTP server I realized that the dates there seem to be specified in seconds from 1900-01-01_00:00:00 on one hand, and on the other I realized that date's option "-d" only allows UNIX epochs using the "@" notation.

Therefore I suggest to allow different starting epochs, possible using a syntax like "date -d '1900-01-01+2287785599'" to print the date and time of 2287785599 seconds past January 1st 1900. ("Like" means I suggest the semantics, but are not really proposing a concrete syntax; possibly there are smarter guy around than me)

Also being able to decode hexadecimal NTP timestamps would be a nice feature: NTp timestamps look like this:
d8bd24ef.a8e2bb68 meaning "Wed, Mar 25 2015 13:13:35.659...", so it's 32 bit for the seconds and another 32 bit for the fractional seconds (see page 9 of the PostScript or PDF version of RFC 1305: "NTP timestamps are represented as a 64-bit
unsigned fixed-point number, in seconds relative to 0h on 1 January 1900. The integer part is in the
first 32 bits and the fraction part in the last 32 bits.")

Maybe a "tagged" syntax like "-d NTP:d8bd24ef.a8e2bb6" could be used...

(For consistency other tags like "UNIX:" for the UNIX epoch and "MS-WIN:" for Microsoft Windows could be used. Again smart guys probably know more important epochs than I do)

Regards,
Ulrich

Message #8 received at 20199 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Ulrich Windl <Ulrich.Windl <at> rz.uni-regensburg.de>, 
 20199 <at> debbugs.gnu.org
Subject: Re: bug#20199: Enhancement request for date's "-d" option: different
 epochs
Date: Wed, 25 Mar 2015 13:10:04 +0000

On 25/03/15 12:26, Ulrich Windl wrote:
> Hi!
> 
> I'm not subscribed to this list, and I hope this is the right place to report an enhancement request as there seems to be no bugzilla for that.
> Anyway: When downloading the current leap seconds list for out NTP server I realized that the dates there seem to be specified in seconds from 1900-01-01_00:00:00 on one hand, and on the other I realized that date's option "-d" only allows UNIX epochs using the "@" notation.
> 
> Therefore I suggest to allow different starting epochs, possible using a syntax like "date -d '1900-01-01+2287785599'" to print the date and time of 2287785599 seconds past January 1st 1900. ("Like" means I suggest the semantics, but are not really proposing a concrete syntax; possibly there are smarter guy around than me)
> 
> Also being able to decode hexadecimal NTP timestamps would be a nice feature: NTp timestamps look like this:
> d8bd24ef.a8e2bb68 meaning "Wed, Mar 25 2015 13:13:35.659...", so it's 32 bit for the seconds and another 32 bit for the fractional seconds (see page 9 of the PostScript or PDF version of RFC 1305: "NTP timestamps are represented as a 64-bit
> unsigned fixed-point number, in seconds relative to 0h on 1 January 1900. The integer part is in the
> first 32 bits and the fraction part in the last 32 bits.")
> 
> Maybe a "tagged" syntax like "-d NTP:d8bd24ef.a8e2bb6" could be used...
> 
> (For consistency other tags like "UNIX:" for the UNIX epoch and "MS-WIN:" for Microsoft Windows could be used. Again smart guys probably know more important epochs than I do)

Note offsets can be negative, so you could set the offset like:

  $ sec=1234567890
  $ date -d @$(($sec + $(date -d 1/1/1900 +%s)))
  Tue Feb 14 23:56:51 GMT 1939

cheers,
Pádraig.

Message #11 received at 20199 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Ulrich Windl <Ulrich.Windl <at> rz.uni-regensburg.de>, 
 20199 <at> debbugs.gnu.org
Subject: Re: bug#20199: Enhancement request for date's "-d" option: different
 epochs
Date: Wed, 25 Mar 2015 13:16:57 +0000

On 25/03/15 13:10, Pádraig Brady wrote:
> On 25/03/15 12:26, Ulrich Windl wrote:
>> Hi!
>>
>> I'm not subscribed to this list, and I hope this is the right place to report an enhancement request as there seems to be no bugzilla for that.
>> Anyway: When downloading the current leap seconds list for out NTP server I realized that the dates there seem to be specified in seconds from 1900-01-01_00:00:00 on one hand, and on the other I realized that date's option "-d" only allows UNIX epochs using the "@" notation.
>>
>> Therefore I suggest to allow different starting epochs, possible using a syntax like "date -d '1900-01-01+2287785599'" to print the date and time of 2287785599 seconds past January 1st 1900. ("Like" means I suggest the semantics, but are not really proposing a concrete syntax; possibly there are smarter guy around than me)
>>
>> Also being able to decode hexadecimal NTP timestamps would be a nice feature: NTp timestamps look like this:
>> d8bd24ef.a8e2bb68 meaning "Wed, Mar 25 2015 13:13:35.659...", so it's 32 bit for the seconds and another 32 bit for the fractional seconds (see page 9 of the PostScript or PDF version of RFC 1305: "NTP timestamps are represented as a 64-bit
>> unsigned fixed-point number, in seconds relative to 0h on 1 January 1900. The integer part is in the
>> first 32 bits and the fraction part in the last 32 bits.")
>>
>> Maybe a "tagged" syntax like "-d NTP:d8bd24ef.a8e2bb6" could be used...
>>
>> (For consistency other tags like "UNIX:" for the UNIX epoch and "MS-WIN:" for Microsoft Windows could be used. Again smart guys probably know more important epochs than I do)
> 
> Note offsets can be negative, so you could set the offset like:
> 
>   $ sec=1234567890
>   $ date -d @$(($sec + $(date -d 1/1/1900 +%s)))
>   Tue Feb 14 23:56:51 GMT 1939

Actually we can use date's relative date support for this:

  $ date -d '1900-01-01 +1234567890 seconds'
  Tue Feb 14 23:56:51 GMT 1939

cheers,
Pádraig.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.