Hey Ozz!

 ON> Coming soon...

:::shudder:::

Why bother?  If there is not a current and/or past application then what is the
 purpose of creating one that obviously is flawed and will introduce bugs given
 the corrupt offsets for at least half of the offsets listed in fts-4008.002? 
Wouldn't it be more prudent to correct that documentation and use strftime's
supported %z that honours the original intent of offsets in the first place? 
It seems to me that this is the PERFECT opportunity to right a past wrong.

 ON> In the Pascal world we have FormatDatetime

I noticed that when doing a search the other day.  Not bad but strftime() is
better methinks.

 ON> In Python we have datetime.datetime.now().strftime("%d %b %y  %T"

Also perl, php, c, c++, ruby, etc.  Has been for ages.  Too bad pascal cannot
keep up with the (strf)times eh?  ;-)

 ON> Thanks to you showing me %T

See http://man7.org/linux/man-pages/man3/strftime... for all the
specifiers.  They should be the same for all languages/interpreters/scripter. 
The coreutils date runtime also includes a few switches for compatibilty with
certain formats such as --iso-8601 which is not in strftime() but can easily be
 reproduced with the correct specifiers.  Piece of cake ... including the
obsolete FTN datetime stamp.  ;-)

However %z will ALWAYS output the + character where applicable such as in UTC
based systems;

  date +%z = +0000

You will have to add a routine to strip it which will break other apps that
follow the real world standards for utc offsets.  Whoever wrote fts-4008.002
should hang their head in shame.  :::sigh:::

Life is good,
Maurice

... Don't cry for me I have vi.
--- GNU bash, version 5.0.2(1)-release (x86_64-pc-linux-gnu)
 * Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)
SEEN-BY: 124/5013 5014 5015 5016 130/803 154/10 19/33 203/0 221/0 229/426
SEEN-BY: 240/5832 261/38 280/464 5003 310/31 31999/99 387/21 396/45 423/120
SEEN-BY: 770/1