[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Is date function in error

From: Leslie S Satenstein
Subject: Is date function in error
Date: Mon, 22 Jan 2018 04:20:09 +0000 (UTC)

The ISO rule for a week number states that the first week of the year always 
contains 4 January.  Week2 starts on the 7th of January (ISO)
The Gnome calendar (gnome 3.26 dropdown) identifies 21 January as being in week 
number 4, which I deem to be correct.
Here is some cut and pastes  First is cal output    
    January 2018
Su Mo Tu We Th Fr Sa
         1  2    3    4   5  6            <<week1 as year includes Thursday
  7     8  9   10  11 12 13
14   15 16  17  18 19 20
21   22  23 24  25  26 27   <<week4 in year
28 29 30 31

Date function is my concern.
date "+%U  %V %W"      The date command with each option should display the 
specific week number. 
03  03 03                           <<<<<<<<  Result.   Should it be a 03 04 03 
if we use %V     ???
today is Sun Jan 21 23:01:40 EST 2018
      From man pages for date 
  %U     week number of year, with Sunday as first day of week (00..53)

   %V     ISO week number, with Monday as first day of week (01..53)

   %W     week number of year, with Monday as first day of week (00..53)
I suspect that date +%V is in error.

 Leslie Satenstein
Montréal Québec, Canada


    On Sunday, January 21, 2018, 9:42:53 PM EST, Pádraig Brady <address@hidden> 
 On 21/01/18 11:57, David Sastre wrote:
> Hello,
> I have been recently playing around with seccomp and the coreutils source
> code and was wondering about the feasibility of implementing seccomp
> filters in the tools.
> The main benefit for the project would be offering the possibility of
> reducing exploitability by reducing the system calls a program might make,
> using a whitelist.
> Searching the mail archives of the project for discussions around this
> topic has not been fruitful, hence my asking.
> I have tested locally with some of the easiest examples possible (true and
> echo) and a, quite possibly, very naive implementation; but it seems to
> work as expected.
> If I where to put some effort in this, and provided this functionality is
> made explicitly GNU/Linux dependant and optional, would there be interest
> from the group? I would most probably require assistance with the autotools
> changes required, not to mention code review.
> My main inspiration for this request is the OpenBSD pledge()[1] syscall,
> which is applied to the base system (containing most of the equivalent
> tools in GNU/Linux land). You can check an example[2] on the 'echo' tool
> source code.
> Regards and thanks in advance for any feedback, I would love to hear from
> the devs even in the case this request is considered not useful.
> [1]
> [2]


I'm not convinced of the generality of using seccomp in all utils,
because if it's optionally enabled then one have similar restrictions
using selinux or apparmor etc. (which can also be optionally disabled).
Also this would be adding options for linux specific functionality.
The main use case for seccomp I think is for linux specific "container" tools.
Especially for always installed tools like coreutils, system level
restrictions using selinux or apparmor etc. seem to be more appropriate?

BTW for some seccomp related plumbing in coreutils see this (revert) patch:

thanks for the proposal,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]