2020-02-18 11:31:54 +0100, Joerg Schilling:
[...]
> There is an official and documented way already, call:
>
> time -p command1 | command2
>
> The time utility in POSIX requires to use the -p option to be specified.
> Otherwise, the results are unspecified.
>
&g
Geoff Clare wrote:
> Treating time something like select and [[ would be an alternative way
> around the problem. What you suggest for "use of the time utility" is
> not quite right, though. Use of the time _reserved_word_ should be as
> you say - unspecified unles
Date:Tue, 18 Feb 2020 11:31:54 +0100
From:Joerg Schilling
Message-ID: <5e4bbd1a.ixp7vvhraxdcl4i4%joerg.schill...@fokus.fraunhofer.de>
| There is an official and documented way already, call:
|
| time -p command1 | command2
That's nice, but
Submitted: 2019-06-03 16:36 UTC
Last Modified: 2019-06-03 19:01 UTC
==
Summary:clarify that "alternative time" means
Submitted: 2019-06-03 16:36 UTC
Last Modified: 2019-06-03 16:36 UTC
==
Summary:clarify that "alternative time" means tm_isdst is
positive
Description:
In the tz mailing list (see, e.g.,
&
Date:Tue, 18 Feb 2020 14:50:50 +0100
From:Joerg Schilling
Message-ID: <5e4bebba.XCR/ahv7oqvibm+7%joerg.schill...@fokus.fraunhofer.de>
| If you like to get the previous POSIX behavior, call:
|
| time -p some-command
|
| This is what POSIX did requ
Submitted: 2019-06-03 16:36 UTC
Last Modified: 2019-07-01 20:47 UTC
==
Summary:clarify that "alternative time" means
:2.4
==
Date Submitted: 2022-04-26 15:51 UTC
Last Modified: 2022-04-26 15:51 UTC
==
Summary:“time” vs. Korn Shell
:The meaning of "Daylight Saving Time" should be
clarified
Description:
The term "Daylight Saving Time" is used in a number of places in the
specification.
In much of the world, it refers to the time during the summer when clocks
are turned forward from standard tim
Stephane Chazelas wrote:
> 2020-02-18 11:31:54 +0100, Joerg Schilling:
> [...]
> > There is an official and documented way already, call:
> >
> > time -p command1 | command2
> >
> > The time utility in POSIX requires to use the -p option to be speci
2020-02-18 14:50:50 +0100, Joerg Schilling:
[...]
> There however is a shell that has massive problems: "zsh".
> zsh cannot time functins or builtins at all
Zsh's "time" keyword reports *process* resource usage (for each
component of the timed pipeline).
If ther
lt;5e4bbd1a.ixp7vvhraxdcl4i4%joerg.schill...@fokus.fraunhofer.de>
| There is an official and documented way already, call:
|
| time -p command1 | command2
That's nice, but in a POSIX compatible shell (the FreeBSD shell in
this case)
fbsh $ time() { command time -p "$@"
e been amended to allow the ksh88 behaviour at that time. The end
| result would be the same, just the timing would be different.
That might or might not be correct, it is impossible to say now - after
all "select" was known at the time, and not standardised, my guess is
that the reserved w
:The meaning of "Daylight Saving Time" should be
clarified
==
Relationships ID Summary
--
related to 0001253 clarify that "a
> | We need a formal interpretation saying that there is a defect in
> | the standard in order for those systems not to have to remove the
> | time keyword from their "sh" shells. Once we say that there is a
> | defect in the standard, we have to fix it.
>
> Let m
Priority: normal
Status: Under Review
Name: Don Cragun
Organization:
User Reference:
Section:time
Page Number:916-919
Line Number:35505-35633
Interp Status
have been amended to allow the ksh88 behaviour at that time. The end
> | result would be the same, just the timing would be different.
>
> That might or might not be correct, it is impossible to say now - after
> all "select" was known at the time, and not standardised,
http://austingroupbugs.net/view.php?id=1234
We agreed this item is still undergoing some discussions on the reflector and
we will
revisit status at the next meeting.
Bug 1253: clarify that "alternative time" means tm_isdst is positive Accepted
as Marked
http://austingroupbugs.net/view.ph
Submitted: 2019-06-03 16:36 UTC
Last Modified: 2019-07-15 15:19 UTC
==
Summary:clarify that "alternative time" means
Submitted: 2019-06-03 16:36 UTC
Last Modified: 2019-07-15 15:19 UTC
==
Summary:clarify that "alternative time" means
Priority: normal
Status: New
Name: steffen
Organization:
User Reference:
Section:time
Page Number:3299
Line Number:111068-111069
Interp Status
Stephane Chazelas wrote:
> Note that AT&T ksh and bosh revert to calling the standalone
> time utility in that case so they can't be used to time
> builtin/functions.
Well, if you enforce to implement the old POSIX behavior, you get what the old
POSIX definition says: timin
Robert & Geoff have been arguing about whether or not giving a struct tm to
mktime() that specifies a time in the gap between standard time and daylight
time is allowed to be treated as an error (assuming that the seconds since the
Epoch would otherwise fit in a time_t).
Robert is arguing
(you will have seen from my earlier reply here today, that the
tzdata error will be corrected) - but it really just boils down to this.
| Okay, let's examine the text in C89/C90:
|
| The mktime function converts the broken-down time, expressed as
| local time, in the str
t as a courtesy) of the longer message, as it seems to be the
crux of the matter.
> | Okay, let's examine the text in C89/C90:
> |
> | The mktime function converts the broken-down time, expressed as
> | local time, in the structure pointed to by timeptr into a
--
The following is a suggested resolution which just covers the originally
raised issue of the allowed behaviour for "non-existent" times and the
function's error handling.
The side-issue of how the conversion from broken-do
go. No grammar changes are required at all.
But:
| and adding the time reserved
| word on top of the pipefail changes instead.
That is what cannot be done. We cannot at this late stage reverse the
decision of the original standard not to make time a required reserved
word - making it eve
orrect. That doesn't mean that a new keyword couldn't
produce output, which is what time does, and if it did, its output would
logically get redirected along with that of the commands it runs (which would
be then subjected to their own more specific redirections, as the fantasy
examples I ga
:The meaning of "Daylight Saving Time" should be
clarified
==
Relationships ID Summary
--
related to 0001253 clarify that "a
.
This is one of the areas where the C standard can be considered broken, leaving
Time Zone handling unspecified. As a backwards compatibility matter changing
the tm struct to accommodate time zone info properly is not indicated, by
either standard. It breaks too much code that relies on the current
--
The POSIX locale default date format:%a %b %e %H:%M:%S %Z
%Ycontains two pieces of information beyond the minimum of date and
time required for other locales: the day name (%a) and the time zone (%Z).
Most implementations include these in the default date output
Priority: normal
Status: Under Review
Name: Don Cragun
Organization:
User Reference:
Section:time
Page Number:916-919
Line Number:35505-35633
Interp Status
The thing is, various shells have implemented time as keyword, so this bug is
trying to get the standard to reflect actual practice that ignored that
Rationale. The debate is more some things allowed to utilities aren't allowed
for keywords, and vice versa, so there are advantages to both
culates seconds since the Epoch as specified in XBD 4.16
> | then applies a timezone adjustment of 5 hours and (depending on tm_isdst
> | and the specified date and time) a seasonal adjustment of 1 hour (with
> | implementation-defined start and end times, but we can eliminate that
&
On 2/14/20 5:19 PM, Robert Elz wrote:
> It is not that I have anything against a time reserved word, though
> being a reserved word rather than a builtin, or special builtin does
> make it impossible to redirect (as has been noted) and also raises
> questions as to what exactly happ
ed a formal interpretation saying that there is a defect in
| the standard in order for those systems not to have to remove the
| time keyword from their "sh" shells. Once we say that there is a
| defect in the standard, we have to fix it.
Let me interpret that, and see if I understand co
16:50 UTC
==
Summary:clock_nanosleep() TIMER_ABSTIME: if rmtp is
non-NULL, set it to clock_id's time value when returning.
Description:
Assuming clock_id is a valid and supported clock, if TIMER_ABSTIME i
t is a likely choice for an existing script, function or alias name.
I don't think anything with time in its name would be right anyway, as
I said earlier (much more information is typically available than that,
and even if it was not to be required, a name that better suited the
complete commo
2023-11-20 17:30:32 +, Austin Group Bug Tracker via austin-group-l at The
Open Group:
[...]
> On page 2920 line 97596 section find (-newer), change:The
> primary shall evaluate as true if the modification time of the current file
> is more recent than the modification time of the f
, leaving
Time Zone handling unspecified. As a backwards compatibility matter changing
the tm struct to accommodate time zone info properly is not indicated, by
either standard. It breaks too much code that relies on the current definition
of the tm_year and tm_isdst fields. The people that can
X requires
| that mktime() calculates seconds since the Epoch as specified in XBD 4.16
| then applies a timezone adjustment of 5 hours and (depending on tm_isdst
| and the specified date and time) a seasonal adjustment of 1 hour (with
| implementation-defined start and end times,
:The meaning of "Daylight Saving Time" should be
clarified
==
Relationships ID Summary
--
related to 0001253 clarify that "a
Submitted: 2019-06-03 16:36 UTC
Last Modified: 2019-07-01 19:53 UTC
==
Summary:clarify that "alternative time" means
this.
It is possible for the broken down local time passed to mktime() to
represent a time that never existed (eg: a time in the gap (most commonly
hour) when summer time commences, and the clock skips forward from
NN:59 to PP:00 (usually, gaps shorter than an hour exist, but for our
purposes her
s where the C standard can be considered broken,
> leaving Time Zone handling unspecified. As a backwards compatibility matter
> changing the tm struct to accommodate time zone info properly is not
> indicated, by either standard. It breaks too much code that relies on the
> current definition
:The meaning of "Daylight Saving Time" should be
clarified
==
Relationships ID Summary
--
related to 0001253 clarify that "a
id=267#c5990
> --
> Suggested changes ...
[...]
> [...] to:When
> time is used in any of the following circumstances, via a simple
> command for which the word time is the command name (see [xref to
> 2.9.1.1]), and none of the characters in the word time is quoted,
> the re
ndard requires (probably all of them).
We need a formal interpretation saying that there is a defect in
the standard in order for those systems not to have to remove the
time keyword from their "sh" shells. Once we say that there is a
defect in the standard, we have to fix it.
So what I would sug
Robert Elz wrote, on 24 Feb 2020:
>
> But we really do not need to defer bug 267 until all that is worked out,
> this will take a long time, as not only do we need a proposal, we need
> implementation experience, and then application use to verify it is
> suitable, and should
Date:Sat, 15 Feb 2020 17:56:36 -0500
From:Chet Ramey
Message-ID: <17c5318a-a4f7-8bd8-8792-c1ad4d82b...@case.edu>
| The only reason to specify it as a reserved word is to time pipelines.
Yes, that much I understood, at least the intent.
| You can time bu
--
I'm sure this has been discussed at least once before, but on the mailing
list not in Mantis. When the specified time does not exist because it is in
the gap created by the change to daylight saving time and tm_isdst is -1,
mktime() i
light before those systems were certified, the standard would
> | have been amended to allow the ksh88 behaviour at that time. The end
> | result would be the same, just the timing would be different.
>
> That might or might not be correct, it is impossible to say now - after
> a
Date:Tue, 18 Feb 2020 09:58:32 -0500
From:Chet Ramey
Message-ID: <22f16ef4-41cf-60b0-5968-f608dc988...@case.edu>
| The 1992 version of the standard knew about time, standardized it as part
| of the UPE, and acknowledged that it worded the definition to all
etation is required.
Interpretation response:
The standard clearly states that when an unsuccessful call to
mktime() returns (time_t)-1 it sets errno to [EOVERFLOW], and
conforming implementations must conform to this.
Rationale:
The RETURN VALUE section on the mktime() page states:
If the time
On 2/15/20 9:42 PM, Robert Elz wrote:
> Date:Sat, 15 Feb 2020 17:56:36 -0500
> From:Chet Ramey
> Message-ID: <17c5318a-a4f7-8bd8-8792-c1ad4d82b...@case.edu>
>
> | The only reason to specify it as a reserved word is to time pipelines.
--
Assuming bug http://austingroupbugs.net/view.php?id=1253 is accepted, the
changes should be ...
On page 280 line 5945 section 8.3, change:The
time has the same format as offset except that no leading
sign ('-' or '+&
light Saving Time" should be clarified Accepted as
Marked
https://austingroupbugs.net/view.php?id=1788
This item is marked for TC1-2024.
It was noted that the resolution of this bug should just address
the missing definitions. Any additional changes related to tzname[]
etc. should be the su
n XBD 4.16
| then applies a timezone adjustment of 5 hours and (depending on tm_isdst
| and the specified date and time) a seasonal adjustment of 1 hour (with
| implementation-defined start and end times, but we can eliminate that
| by including a rule in the TZ value). There is nothing u
Hi!
Issue 8 Draft 2.1 states what follows.
108150 min number
108151Set the value of MIN to number. MIN is used in non-canonical mode
input processing
108152(icanon).
108153 time number
108154Set the value of TIME to number. TIME is used in non-canonical mode
input processing
Date:Tue, 25 Feb 2020 17:47:23 + (UTC)
From:shwaresyst
Message-ID: <1701159045.321204.1582652843...@mail.yahoo.com>
| The thing is, various shells have implemented time as keyword, so this bug
| is trying to get the standard to reflect actual practic
Robert Elz wrote:
> | There is an official and documented way already, call:
> |
> | time -p command1 | command2
>
> That's nice, but in a POSIX compatible shell (the FreeBSD shell in
> this case)
>
> fbsh $ time() { command time -p "$@"; }
The
hat care would need to be taken to add using the
> correct units, but an implementation could provide a specification to
> allow programs to discover what the precision actually is.
I may have misled you a little in the way I worded a previous email.
It's not the time_t type itself that you can&#
On 2/18/20 10:36 AM, Robert Elz wrote:
> Date:Tue, 18 Feb 2020 09:58:32 -0500
> From:Chet Ramey
> Message-ID: <22f16ef4-41cf-60b0-5968-f608dc988...@case.edu>
>
> | The 1992 version of the standard knew about time, standardized it as part
), change:The
>> primary shall evaluate as true if the modification time of the current file
>> is more recent than the modification time of the file named by the pathname
>> file.to:The primary shall evaluate as true
>> if the modification time of the current file is more
her summer time applies or
not (except that it insists on calling it by the idiotic US label).
| With tm_idsdt=-1 it will only change on the rare occasions when
| the calculated time is in the gap.
Nonsense. mktime() allows for out of range values for all of the
(then existing) fields of exce
#c6049
--
Change lines 43850-43854 from:The mktime() function
shall convert the broken-down time, expressed as local time, in the
structure pointed to by timeptr, into a time since the Epoch value
with the same encoding as that of
in the
> standard (C or POSIX) is there anything which actually says this
> is supposed to happen. All it says about mktime() with tm_isdst = -1
> is that it attempts to work out whether summer time applies or
> not (except that it insists on calling it by the idiotic US label).
We a
o be adding timegm() now.
It is too late to add timegm() in Issue 8. It will automatically get
added in Issue 9 as that will (presumably) align with C23 or later.
> | By a strict reading, you may be right, but it is strongly implied by
> | "shall be set to represent the specified
Given the wide variaty of synchronization primitives available in the
theoretical field, what was POSIX's criteria for standardization at the time
for pthread and real-time option groups' interfaces?
Are there examples of and rationales for synchronization primitives being
exc
: normal
Status: Closed
Name: Stephane Chazelas
Organization:
User Reference:
Section:"time" utility
Page Number:3259
Line Number:109327
Int
specification of mktime() says (lines 43850-4)
The mktime( ) function shall convert the broken-down time, expressed
as
local time, in the structure pointed to by timeptr, into a time since
the
Epoch value with the same encoding as that of the values returned by
time( ). The original
--
The POSIX locale default date format:%a %b %e %H:%M:%S %Z
%Ycontains two pieces of information beyond the minimum of date and
time required for other locales: the day name (%a) and the time zone (%Z).
Most implementations include these in the
Date:Tue, 18 Feb 2020 11:31:54 +0100
From:Joerg Schilling
Message-ID: <5e4bbd1a.ixp7vvhraxdcl4i4%joerg.schill...@fokus.fraunhofer.de>
| There is an official and documented way already, call:
|
| time -p command1 | command2
That's actually s
unspecified results, because Usage: is a word that is the concatenation
of a name and a colon. That kind of thing should be fixed whatever else
happens, and as making time back being an unspecified reserved word means
changes all around that area (and ideally we need a method to introduce new
reserved wor
net/view.php?id=1614#c6031
>
> I know this:
>
> A negative value for tm_isdst shall cause mktime() to attempt to
> determine
> whether Daylight Savings Time is in effect for the specified time.
>
> and what your note says about it, but note that it says "attempt to
&
--
On page 2920 line 97596 section find (-newer), change:The
primary shall evaluate as true if the modification time of the current file
is more recent than the modification time of the file named by the pathname
file.to:The primary shall evaluate as true
if the modification time of the
--
Suggested resolution ...
On page 113 line 3186 section 4.16 Seconds Since the Epoch,
change:The relationship between the actual time of day and the
current value for seconds since the Epoch is
unspecified.to:The relationship between the actual
date and time in Coordinated
No keyword, on its own, presently in the standard is required to produce output
that may be redirected. What redirections are permitted apply to utilities used
with those keywords, not the keywords themselves, and this is where the
conflict appears - does a stderr redirect with time as a
: Editorial
Priority: normal
Status: Closed
Name: Stephane Chazelas
Organization:
User Reference:
Section:"time" utility
Page Number:3259
Line Number:1093
ded now for that is the details. A month seems
like a reasonable time to clean that up.
| If your and Chet's new proposal looks promising, we will likely
| abandon the current direction
Now I am back to thinking that you are expecting something new within
a month, and that's unre
:The meaning of "Daylight Saving Time" should be
clarified
==
Relationships ID Summary
--
related to 0001253 clarify that "a
==
Summary:timeout - new utility: run a command with a time
limit
Description:
As of today it is very complicated to reliably run a program from within
a sh(1)ell with a timeout, a sh(1)ell can only hardly kill a child after
a timeout without introducing a race, as shown in
ov 2022:
> From:"Geoff Clare via austin-group-l at The Open Group"
>
>
> You seem to be of the opinion that mktime()'s prime purpose is to allow
> people to increment time fields, and get a time_t back. Almost as if
> that is its only use.
Of course I am
ot supported in the locale,
the string shall be empty.
On page 162 line 5150 section 7.3.5.2 LC_TIME C-Language Access, change:
AM_STR The appropriate ante-meridiem affix.
PM_STR The appropriate post-meridiem affix.
T_FMT_AMPM The appropriate time representation in the 12-ho
21:37 UTC
==
Summary:Extend TZ to allow times outside 00-24 range,
permanent DST
Description:
The tzdb project is a widely-used extension to POSIX, and represents the
history of a time zone partly via a final POSIX TZ string represent
On 2/18/20 5:31 AM, Joerg Schilling wrote:
> All shells I am aware detect the -p option in the parser already and switch
> to
> the time utility instead of the time keyword.
Bash doesn't do that; it's not useful and difficult to do using a bison-
based parser.
--
``Th
On 2/18/20 9:59 AM, Robert Elz wrote:
> Why someone would want to time a builtin I'm not sure
> (with the possible exception of elapsed time of wait)
There are people on the bash mailing lists who would like a word.
--
``The lyf so short, the craft so long to lerne.&
() as well.
| This has been a lengthy thread and I have been assuming that if I
| quoted something from the standard earlier in the thread I don't need
| to quote it again.
Sorry, but I, and I expect everyone else, doesn't have the time to
go back and reread all of your previou
tself that you can't do arithmetic on,
No, not misled, I knew what you meant, and I understand that arithmetic
types allow arithmetic, what matters is whether that arithmetic makes
sense in context or not.
| The description of time() says:
|
| The time function determines the c
a WEBEX meeting on 18-Mar-2024 at 11:00 America/New_York
(I cut/pasted the actual date & time, for this particular invitation, from
the calendar info.)
Or even better if it gave the time in UTC, so "at 15:00 UTC" - or whatever
it is this week. Note that the calls are anchored to US Eas
section 7.3.5.2 LC_TIME C-Language Access, change:
AM_STR The appropriate ante-meridiem affix.
PM_STR The appropriate post-meridiem affix.
T_FMT_AMPM The appropriate time representation in the 12-hour clock
format with AM_STR and PM_STR.to:AM_STR The
appropriate ante-meridiem affix; if
==
Summary:timeout - new utility: run a command with a time
limit
==
--
(0005920) geoffclare (manager) - 2022-07-29 11:03
https
:Footnote incorrectly says the time utility is in the
UP option
Description:
In the rationale about command language portability, the time utility has
an asterisk after it to indicate it is in the UP option, but it has been
moved to the Base.
Desired Action:
Move the footnote marker from after
m with a grain of salt as well.
| In this case, it is clear from the use of "any" in "corrected for
| timezone and any seasonal time adjustments" that either a seasonal
| adjustment is made or the value resulting from the timezone adjustment
| is used without making a se
t some random "the standard
> says" without any clue what part of it you mean.
This has been a lengthy thread and I have been assuming that if I
quoted something from the standard earlier in the thread I don't need
to quote it again.
> | In this case, it is clear from the u
--
The POSIX locale default date format:%a %b %e %H:%M:%S %Z
%Ycontains two pieces of information beyond the minimum of date and
time required for other locales: the day name (%a) and the time zone (%Z).
Most implementations include these in the default date
Priority: normal
Status: Resolved
Name: steffen
Organization:
User Reference:
Section:time
Page Number:3299
Line Number:111068-111069
Interp Status
alues of the tm_wday and tm_yday
components of the structure are set appropriately, and the other
components are set to represent the specified calendar time, but
with their values forced to the ranges indicated above; the final
value of tm_mday is not set until tm_mon and tm_year are dete
g for wording on this item. and will start on this next time.
Bug 1616: Standardize mktemp utility OPEN
https://austingroupbugs.net/view.php?id=1616
We will need a sponsor; it is not suitable for inclusion in Issue 8.
ACTION: Eric to ask The Open Group to sponsor adding the mktemp utility
(for Is
Robert Elz wrote:
> I fail to see why any real importance is given to shell speed.
The shell speed has a major influence on the execution time for the "configure"
scripts.
The ksh93 variant that is part of OpenSolaris is e.g. nearly twice as fast (in
terms of wall clock ti
1 - 100 of 2444 matches
Mail list logo
