Useful zsh/datetime things

Useful zsh/datetime things

[Bart Schaefer]

In the latest 4.1.1 dev version from CVS, we have the zsh/datetime module,
which defines a strftime builtin and the EPOCHSECONDS variable.  Here are
a couple of simple helper functions that make use of these:

function ctime {
  # Print the current or argument time in standard format
  local time=${1:-$EPOCHSECONDS}
  strftime "%a %b %e %H:%M:%S %Y" $time
}
function starttime {
  # Print the time this shell was started
  # (doesn't work if SECONDS has been reset)
  typeset -i SECONDS=$SECONDS	# No floating point
  ctime $((EPOCHSECONDS - SECONDS))
}
function rfcdate {
  # Like GNU "date -R"
  strftime "%a, %e %b %Y %H:%M:%S %z" $EPOCHSECONDS
}

A useful addition to strftime would be an option to assign the result to a
parameter, similar to the -A and -H options of "stat" (from zsh/stat).

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Useful zsh/datetime things

[Phil Pennock]

On 2003-10-09 at 17:27 +0000, Bart Schaefer wrote:
> A useful addition to strftime would be an option to assign the result to a
> parameter, similar to the -A and -H options of "stat" (from zsh/stat).

Reminding myself about this stuff led me to try something, the results
of which have me slightly confused.  I'm trying to figure out what's
happening with "print -l" here.

% stat -H foo -s .
% print -l ${(kv)foo} | pr -at2
% print -l "${(@kv)foo}" | pr -at2

The second command doesn't give proper results, since there is no value
shown for the key 'link', so after that things are mis-placed.

But why is there not a blank line?  If the key exists but is undefined,
it's the empty string?  The third command shows that when treated as the
argument "", a blank line is shown and pr(1) can recombine things
correctly.

Given that there's no white-space splitting happening, why does the
second print differ from the others?

% print -l alpha '' beta '' gamma
% s=''
% print -l alpha $s beta $s gamma
% print -l alpha "$s" beta "$s" gamma

% print $ZSH_VERSION
4.0.6

If I had SH_WORD_SPLIT set, this would make more sense, but I don't.
Behaviour verified with "zsh -f".

I'm missing something really obvious, aren't I?
-- 
2001: Blogging invented. Promises to change the way people bore strangers with
banal anecdotes about their pets. <http://www.thelemon.net/issues/timeline.php>

Re: Useful zsh/datetime things

[Bart Schaefer]

On Oct 9,  5:49pm, Phil Pennock wrote:
}
} % stat -H foo -s .
} % print -l ${(kv)foo} | pr -at2
} % print -l "${(@kv)foo}" | pr -at2
} 
} The second command doesn't give proper results, since there is no value
} shown for the key 'link', so after that things are mis-placed.
} 
} But why is there not a blank line?

Because an unquoted empty string always disappears.  It just happens that
the easiest way to get an unquoted empty string is to expand an unset or
empty-valued parameter (the former assuming setopt no_unset).

"Not split" (in the sh_word_split sense) is not equivalent to "quoted".

You'd get strange effects if it didn't work this way; e.g., $* would
always substitute an empty string, even when $# == 0.

Re: Useful zsh/datetime things

[Phil Pennock]

On 2003-10-10 at 04:40 +0000, Bart Schaefer wrote:
> Because an unquoted empty string always disappears.  It just happens that
> the easiest way to get an unquoted empty string is to expand an unset or
> empty-valued parameter (the former assuming setopt no_unset).
> 
> "Not split" (in the sh_word_split sense) is not equivalent to "quoted".

Ah.  Good thing that long habit keeps me using "$@" instead of dropping
the quotes to get $@ for zsh then.

Any other side-effects to not quoting variables in zsh?  Backslash
degree-of-toothpickiness, I suppose.

> You'd get strange effects if it didn't work this way; e.g., $* would
> always substitute an empty string, even when $# == 0.

And you could of course get an empty string by explicitly using "$*" or
"${*:-}" which would be the same, but make the intention explicit.  Ta.
-- 
2001: Blogging invented. Promises to change the way people bore strangers with
banal anecdotes about their pets. <http://www.thelemon.net/issues/timeline.php>

Re: Useful zsh/datetime things

[Peter Stephenson]

Bart Schaefer wrote:
> function rfcdate {
>   # Like GNU "date -R"
>   strftime "%a, %e %b %Y %H:%M:%S %z" $EPOCHSECONDS
> }

Sure the %z shouldn't be %Z?  Solaris doesn't like %z.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Useful zsh/datetime things

[Phil Pennock]

On 2003-10-09 at 19:04 +0100, Peter Stephenson wrote:
> Sure the %z shouldn't be %Z?  Solaris doesn't like %z.

%z is a common extension to strftime(), which gives the off-set
numerically.

Eg:

 %Z CEST
 %z +0200

The %z is not part of POSIX.
-- 
2001: Blogging invented. Promises to change the way people bore strangers with
banal anecdotes about their pets. <http://www.thelemon.net/issues/timeline.php>

Re: Useful zsh/datetime things

[Bart Schaefer]

On Oct 9,  7:04pm, Peter Stephenson wrote:
}
} Bart Schaefer wrote:
} > function rfcdate {
} >   # Like GNU "date -R"
} >   strftime "%a, %e %b %Y %H:%M:%S %z" $EPOCHSECONDS
} > }
} 
} Sure the %z shouldn't be %Z?  Solaris doesn't like %z.

On Oct 9,  6:12pm, Phil Pennock wrote:
}
} %z is a common extension to strftime(), which gives the off-set
} numerically.

Which is how it's supposed to be formatted for RFC{2,}822 et al., and is
how `date -R` does it.  Is there a POSIX way to get the zone hours offset
from UT?

Re: Useful zsh/datetime things

[Phil Pennock]

On 2003-10-10 at 02:15 +0000, Bart Schaefer wrote:
> Which is how it's supposed to be formatted for RFC{2,}822 et al., and is
> how `date -R` does it.  Is there a POSIX way to get the zone hours offset
> from UT?

[
 It's actually adopted from ISO 8601.  The standards track RFC
 introducing an ISO 8601 profile for Internet use is RFC 3339.
]

POSIX: Not that I've seen, but I'm hardly a POSIX spec expert.

I submitted a patch for FreeBSD 3.x some time ago; the change-request PR
was closed a couple of years later on the basis that the functionality
had already been added, and referred to the relevant PR which showed it
-- the same one!  They closed my PR by referring to my PR.
Head-in-hands moment ...

Some rough code from me, submitted explicitly for a BSD-licensed OS and
available for zsh is at:

 <URL:http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/20159>

But do you want the module to be explicitly extending the OS strftime()
if that's missing expansions?  Would be a powerful reason to _use_ the
module.
-- 
2001: Blogging invented. Promises to change the way people bore strangers with
banal anecdotes about their pets. <http://www.thelemon.net/issues/timeline.php>

Re: Useful zsh/datetime things

[Dan Nelson]

In the last episode (Oct 10), Phil Pennock said:
> I submitted a patch for FreeBSD 3.x some time ago; the change-request PR
> was closed a couple of years later on the basis that the functionality
> had already been added, and referred to the relevant PR which showed it
> -- the same one!  They closed my PR by referring to my PR.
> Head-in-hands moment ...
> http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/20159

That url at the bottom of the PR webpage was not added by the
responder.  Gnats automatically adds it to the end of every email.  The
%z commit was made to -CURRENT (4.0 at that time) 5 months before you
submitted your PR.  I'm not sure why it wasn't merged back into -STABLE
(3.4 at that time).

  RCS file: /home/ncvs/src/lib/libc/stdtime/strftime.c,v
  revision 1.25
  date: 2000/01/28 17:40:42;  author: joerg;  state: Exp;  lines: +17 -1
  branches:  1.25.2;

  There were so far only 42 different conversion specifications in
  strftime(3), add another one. :) %z yields the local timezone's
  offset in hours and minutes, as used in RFC822 headers.  There's a
  precedence for this in Lunux' libc, and Internet software (like Perl
  scripts) start using it.

  OKed by (wrt. the code freeze): jkh


-- 
	Dan Nelson
	dnelson@allantgroup.com

Re: Useful zsh/datetime things

[Oliver Kiddle]

Bart wrote:
> A useful addition to strftime would be an option to assign the result to a
> parameter, similar to the -A and -H options of "stat" (from zsh/stat).

Don't really see the point of that. $(...) does the job and it is more
obvious what it does than some option letter.

Would be nice if the second argument would default to $EPOCHSECONDS
though.

Oliver

Re: Useful zsh/datetime things

[Bart Schaefer]

On Oct 9, 11:29pm, Oliver Kiddle wrote:
}
} Bart wrote:
} > A useful addition to strftime would be an option to assign the
} > result to a parameter
} 
} Don't really see the point of that. $(...) does the job and it is more
} obvious

But $(...) forks a copy of the shell, which is a lot more expensive than
assigning to a parameter.

Even an option to set $REPLY would be sufficient.  It doesn't need to take
the name of the parameter as an argument.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Useful zsh/datetime things

[Peter Stephenson]

Oliver Kiddle wrote:
> Bart wrote:
> > A useful addition to strftime would be an option to assign the result to a
> > parameter, similar to the -A and -H options of "stat" (from zsh/stat).
> 
> Don't really see the point of that. $(...) does the job and it is more
> obvious what it does than some option letter.

Well, if you passed it an associative array you could arrange it so that
the element "m" was given the value of the "%m" output, and so on.  But
that looks like overkill.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Useful zsh/datetime things

[Bart Schaefer]

On Oct 9,  5:27pm, Bart Schaefer wrote:
}
} function rfcdate {
}   # Like GNU "date -R"
}   strftime "%a, %e %b %Y %H:%M:%S %z" $EPOCHSECONDS
} }

As this doesn't work without a version of strftime that supports the
nonstandard "%z", here's a replacement:

function rfcdate {
    # As much like GNU "date -R" as possible
    if [[ ${(%):-"%D{%z}"} == [-+]<-> ]]
    then strftime "%a, %e %b %Y %H:%M:%S %z" $EPOCHSECONDS
    else strftime "%a, %e %b %Y %H:%M:%S %Z" $EPOCHSECONDS
    fi
}

The quotes around "%D{%z}" are necessary lest zsh interpret the first
closing brace as the end of the parameter substitution (leaving a stray
second closing brace which becomes part of the comparison).  This does
not seem to be the behavior of other shells -- e.g., bash balances all
nested braces.