Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #207139 > unrolled thread

date(1) in stretch and buster

Back to article view | Back to linux.debian.user

Contents

  date(1) in stretch and buster Reco <recoverym4n@enotuniq.net> - 2019-04-08 17:30 +0200
    Re: date(1) in stretch and buster Étienne Mollier <etienne.mollier@mailoo.org> - 2019-04-08 19:20 +0200
      Re: date(1) in stretch and buster Cindy Sue Causey <butterflybytes@gmail.com> - 2019-04-08 19:30 +0200
        Re: date(1) in stretch and buster "Thomas Schmitt" <scdbackup@gmx.net> - 2019-04-08 19:50 +0200
        Re: date(1) in stretch and buster Étienne Mollier <etienne.mollier@mailoo.org> - 2019-04-08 20:20 +0200
          Re: date(1) in stretch and buster Greg Wooledge <wooledg@eeg.ccf.org> - 2019-04-08 21:30 +0200
      Re: date(1) in stretch and buster Reco <recoverym4n@enotuniq.net> - 2019-04-08 20:10 +0200
    Re: date(1) in stretch and buster Vincent Lefevre <vincent@vinc17.net> - 2019-04-09 15:50 +0200
      Re: date(1) in stretch and buster Gene Heskett <gheskett@shentel.net> - 2019-04-09 20:10 +0200
        Re: date(1) in stretch and buster Greg Wooledge <wooledg@eeg.ccf.org> - 2019-04-09 20:10 +0200
        Re: date(1) in stretch and buster Michael Stone <mstone@debian.org> - 2019-04-09 20:30 +0200
          Re: date(1) in stretch and buster Michael Stone <mstone@debian.org> - 2019-04-09 21:20 +0200
          Re: date(1) in stretch and buster Gene Heskett <gheskett@shentel.net> - 2019-04-09 21:20 +0200
        Re: date(1) in stretch and buster Étienne Mollier <etienne.mollier@mailoo.org> - 2019-04-09 20:40 +0200
          Re: date(1) in stretch and buster Curt <curty@free.fr> - 2019-04-09 22:10 +0200
            Re: date(1) in stretch and buster David Wright <deblis@lionunicorn.co.uk> - 2019-04-09 23:00 +0200
        Re: date(1) in stretch and buster David Wright <deblis@lionunicorn.co.uk> - 2019-04-09 20:40 +0200
          Re: date(1) in stretch and buster Étienne Mollier <etienne.mollier@mailoo.org> - 2019-04-09 20:50 +0200
            Re: date(1) in stretch and buster David Wright <deblis@lionunicorn.co.uk> - 2019-04-09 21:50 +0200
          Re: date(1) in stretch and buster Gene Heskett <gheskett@shentel.net> - 2019-04-09 21:40 +0200
      Re: date(1) in stretch and buster David Wright <deblis@lionunicorn.co.uk> - 2019-04-09 20:30 +0200
        Re: date(1) in stretch and buster Greg Wooledge <wooledg@eeg.ccf.org> - 2019-04-09 21:00 +0200
          Re: date(1) in stretch and buster David Wright <deblis@lionunicorn.co.uk> - 2019-04-09 22:00 +0200
        Re: date(1) in stretch and buster Vincent Lefevre <vincent@vinc17.net> - 2019-04-10 13:40 +0200
          Re: date(1) in stretch and buster David Wright <deblis@lionunicorn.co.uk> - 2019-04-10 18:00 +0200

Page 1 of 2  [1] 2  Next page →

#207139 — date(1) in stretch and buster

	Dear list,

the following thing got my attention recently:

stretch$ TZ=UTC date
Mon Apr  8 15:22:02 UTC 2019
buster$ TZ=UTC date
Mon 08 Apr 2019 03:22:04 PM UTC

It's not that I depend on certain date format in scripts, but I got used
to this 24-hour time format after all these years. And yes, I can commit
into my memory that I can achieve old behaviour with "date -R" or
"busybox date".

My question is - can anyone suggest me appropriate LC_TIME setting that
can show buster's date in stretch's format?

Reco

[toc] | [next] | [standalone]

#207144

On 4/8/19 5:26 PM, Reco wrote:
> 	Dear list,
> 
> the following thing got my attention recently:
> 
> stretch$ TZ=UTC date
> Mon Apr  8 15:22:02 UTC 2019
> buster$ TZ=UTC date
> Mon 08 Apr 2019 03:22:04 PM UTC
> 
> It's not that I depend on certain date format in scripts, but I got used
> to this 24-hour time format after all these years. And yes, I can commit
> into my memory that I can achieve old behaviour with "date -R" or
> "busybox date".
> 
> My question is - can anyone suggest me appropriate LC_TIME setting that
> can show buster's date in stretch's format?
> 

Good Day Reco,

>From Sid:

	$ LC_TIME=en_US.UTF-8 TZ=UTC date
	Mon 08 Apr 2019 05:07:44 PM UTC

	$ LC_TIME=C.UTF-8 TZ=UTC date
	Mon Apr  8 17:08:59 UTC 2019

If you speak C, it looks like a good bet.

Kind Regards,
-- 
Étienne Mollier <etienne.mollier@mailoo.org>

[toc] | [prev] | [next] | [standalone]

#207146

On 4/8/19, Étienne Mollier <etienne.mollier@mailoo.org> wrote:
> On 4/8/19 5:26 PM, Reco wrote:
>> 	Dear list,
>>
>> the following thing got my attention recently:
>>
>> stretch$ TZ=UTC date
>> Mon Apr  8 15:22:02 UTC 2019
>> buster$ TZ=UTC date
>> Mon 08 Apr 2019 03:22:04 PM UTC
>>
>> It's not that I depend on certain date format in scripts, but I got used
>> to this 24-hour time format after all these years. And yes, I can commit
>> into my memory that I can achieve old behaviour with "date -R" or
>> "busybox date".
>>
>> My question is - can anyone suggest me appropriate LC_TIME setting that
>> can show buster's date in stretch's format?
>>
>
> Good Day Reco,
>
> >From Sid:
>
> 	$ LC_TIME=en_US.UTF-8 TZ=UTC date
> 	Mon 08 Apr 2019 05:07:44 PM UTC
>
> 	$ LC_TIME=C.UTF-8 TZ=UTC date
> 	Mon Apr  8 17:08:59 UTC 2019
>
> If you speak C, it looks like a good bet.


My half-penny's worth is that my reaction was, "Now that you said
that, I'd like mine to be in the '2009.04.08' format."

Which then brought to mind that at least some file managers, e.g.
Thunar for sure, allow us the option to alter the date format for e.g.
the "Date Modified" column.

That means those variables are buried in that package's code
somewhere. Somewhere at some point, I encountered a package that
offered a rather large selection that covers a lot more tastes in date
formatting solutions, but I can't remember where I saw that..

Found this over at Tecmint:

https://www.tecmint.com/set-system-locales-in-linux/

locale -k LC_TIME

Very coo AND further implies *WHAT ELSE can that little puppy do*, but
my brain's already cognitively sundowning so am passing the baton on
for someone who can run that full distance. :)

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

[toc] | [prev] | [next] | [standalone]

#207149

Hi,

Cindy Sue Causey wrote:
> I'd like mine to be in the '2009.04.08' format.

  $ date +'%Y.%m.%d'
  2019.04.08


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#207151

Cindy-Sue Causey, on 2019-04-08 :
> Found this over at Tecmint:
>
> https://www.tecmint.com/set-system-locales-in-linux/
>
> locale -k LC_TIME
>
> Very coo AND further implies *WHAT ELSE can that little puppy do*, but
> my brain's already cognitively sundowning so am passing the baton on
> for someone who can run that full distance. :)

Good Day Cindy,

Basically you can tune these variables to build your own
"standard" format for everything related localized information:
- language,
- numeric separators,
- time format,
- sorting order, there is a big warning about this in sort(1),
- monetary symbol,
- etc.

On the other hand, the C lang is a quite convenient setting when
you wish your systems to behave consistently whatever the
localisation of the machine is, whatever the policy of the
country about its standards is; see the move from one standard
to the next between the two versions of Debian spotted by Reco.
C.UTF-8 landed a few Debian versions earlier to give an "Unicode
aware" variant of this behaviour.

See locale(1), locale(5), and eventually locale(7), if you are
interested in the topic.  :)

Kind Regards,
-- 
Étienne Mollier <etienne.mollier@mailoo.org>

[toc] | [prev] | [next] | [standalone]

#207154

I managed to build a locale with a customized LC_TIME setting under
buster.  It's not documented in a straightforward manner anywhere I
could find, so I'm going to spell it all out here.


Step 1: Start with an existing locale definition.

In my case, I am starting with Debian buster's en_US locale, and I am
only going to change one of the variables in the LC_TIME section.


Step 2: Create some directories.

mkdir -p ~/.locale/src

The ~/.locale directory is where the custom locale is going to end up when
it's all done.  In addition to that, you need a temporary working directory
where the locale definition (source) files are going to live.  In my case,
I chose to make this a permanent home rather than a temporary directory.


Step 3: Copy the existing locale definition to the work directory.

cp /usr/share/i18n/locales/en_US ~/.locale/src/

This is a text file that defines the locale's behavior.  You can edit it
with any standard text editor.  You might want to take a moment to look
through it and figure out how it's laid out.  It's pretty straightforward.


Step 4: Modify the locale definition file.

In my case, I wanted to change the date_fmt variable inside the LC_TIME
section.  So first, I logged into a stretch box and found what it was
using:

stretch:~$ locale -k LC_TIME | grep date_fmt
date_fmt="%a %b %e %H:%M:%S %Z %Y"

Next, I edited the ~/.locale/src/en_US file and replaced the date_fmt line.

BEFORE:

% Appropriate date and time representation for date(1)
date_fmt "%a %d %b %Y %r %Z"

AFTER:

% Appropriate date and time representation for date(1)
date_fmt "%a %b %e %H:%M:%S %Z %Y"


Step 5: Compile the locale.

I18NPATH=~/.locale/src/ localedef -f UTF-8 -i en_US ~/.locale/en_US.UTF-8

This creates the directory ~/.locale/en_US.UTF-8 containing several binary
files.  This is what the C library uses.


Step 6: Test it.

buster:~$ date
Mon 08 Apr 2019 02:52:34 PM EDT
buster:~$ LOCPATH=~/.locale date
Mon Apr  8 14:52:38 EDT 2019


Step 7: Set environment variables to make this your new locale upon login.

All you need (assuming you use bash) is:

export LOCPATH="$HOME/.locale"

This will be either really easy, or really hard, depending on how you
login and what kind of Desktop Environment (if any) you use.  Suggested
reading:

https://mywiki.wooledge.org/DotFiles
https://wiki.debian.org/Xsession

In particular, it would be great to hear from anyone who manages to get
this working under GNOME, which is notorious for not allowing easy
customizations of the login environment.

[toc] | [prev] | [next] | [standalone]

#207150

	Hi.

On Mon, Apr 08, 2019 at 07:10:50PM +0200, Étienne Mollier wrote:
> > My question is - can anyone suggest me appropriate LC_TIME setting that
> > can show buster's date in stretch's format?
> 
> 	$ LC_TIME=en_US.UTF-8 TZ=UTC date
> 	Mon 08 Apr 2019 05:07:44 PM UTC
> 
> 	$ LC_TIME=C.UTF-8 TZ=UTC date
> 	Mon Apr  8 17:08:59 UTC 2019
> 
> If you speak C, it looks like a good bet.

Thank you, works as intended. One less problem for the future upgrade.

Reco

[toc] | [prev] | [next] | [standalone]

#207177

On 2019-04-08 18:26:23 +0300, Reco wrote:
> stretch$ TZ=UTC date
> Mon Apr  8 15:22:02 UTC 2019
> buster$ TZ=UTC date
> Mon 08 Apr 2019 03:22:04 PM UTC

This is unrelated to your issue, but note that the correct TZ string
for UTC is "UTC0", not "UTC". See

  http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[toc] | [prev] | [next] | [standalone]

#207193

On Tuesday 09 April 2019 09:38:43 Vincent Lefevre wrote:

> On 2019-04-08 18:26:23 +0300, Reco wrote:
> > stretch$ TZ=UTC date
> > Mon Apr  8 15:22:02 UTC 2019
> > buster$ TZ=UTC date
> > Mon 08 Apr 2019 03:22:04 PM UTC
>
> This is unrelated to your issue, but note that the correct TZ string
> for UTC is "UTC0", not "UTC". See
>
>  
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.htm
>l

Yikes. Can that be actually put into English?

I've read thru it, and the only thing I can come away is that 'if UTC, 
then offset is required, and it can be anything from -23 to +23, 
including your example 0 meaning no offset from UTC.

As it now reads, theres a ton of ambiguity that needs further 
clarification.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#207194

On Tue, Apr 09, 2019 at 02:03:08PM -0400, Gene Heskett wrote:
> Yikes. Can that be actually put into English?

"Use date -u instead."

[toc] | [prev] | [next] | [standalone]

#207196

On Tue, Apr 09, 2019 at 02:03:08PM -0400, Gene Heskett wrote:
>On Tuesday 09 April 2019 09:38:43 Vincent Lefevre wrote:
>
>> On 2019-04-08 18:26:23 +0300, Reco wrote:
>> > stretch$ TZ=UTC date
>> > Mon Apr  8 15:22:02 UTC 2019
>> > buster$ TZ=UTC date
>> > Mon 08 Apr 2019 03:22:04 PM UTC
>>
>> This is unrelated to your issue, but note that the correct TZ string
>> for UTC is "UTC0", not "UTC". See
>>
>>
>> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.htm
>>l
>
>Yikes. Can that be actually put into English?
>
>I've read thru it, and the only thing I can come away is that 'if UTC,
>then offset is required, and it can be anything from -23 to +23,
>including your example 0 meaning no offset from UTC.
>
>As it now reads, theres a ton of ambiguity that needs further
>clarification.

There's a discrepency between the historic posix definition of the TZ 
environment variable, and how it works on a modern system. There's an 
official workaround that I've never actually seen used in the wild. It 
doesn't matter in practice.

Mike Stone

[toc] | [prev] | [next] | [standalone]

#207206

On Tue, Apr 09, 2019 at 03:11:27PM -0400, Gene Heskett wrote:
>The point I was trying to make Mike, is, if thats to be a std, its an
>extremely obtuse way of writing that std. Consequently I suspect it will
>be 100% ignored. And folks will continue to muddle along just fine. :)

It reads fine to me, but it's describing functionality that's been 
obsolete for decades so it doesn't really matter.

Mike Stone

[toc] | [prev] | [next] | [standalone]

#207207

On Tuesday 09 April 2019 14:28:18 Michael Stone wrote:

> On Tue, Apr 09, 2019 at 02:03:08PM -0400, Gene Heskett wrote:
> >On Tuesday 09 April 2019 09:38:43 Vincent Lefevre wrote:
> >> On 2019-04-08 18:26:23 +0300, Reco wrote:
> >> > stretch$ TZ=UTC date
> >> > Mon Apr  8 15:22:02 UTC 2019
> >> > buster$ TZ=UTC date
> >> > Mon 08 Apr 2019 03:22:04 PM UTC
> >>
> >> This is unrelated to your issue, but note that the correct TZ
> >> string for UTC is "UTC0", not "UTC". See
> >>
> >>
> >> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.
> >>htm l
> >
> >Yikes. Can that be actually put into English?
> >
> >I've read thru it, and the only thing I can come away is that 'if
> > UTC, then offset is required, and it can be anything from -23 to
> > +23, including your example 0 meaning no offset from UTC.
> >
> >As it now reads, theres a ton of ambiguity that needs further
> >clarification.
>
> There's a discrepency between the historic posix definition of the TZ
> environment variable, and how it works on a modern system. There's an
> official workaround that I've never actually seen used in the wild. It
> doesn't matter in practice.
>
> Mike Stone

The point I was trying to make Mike, is, if thats to be a std, its an 
extremely obtuse way of writing that std. Consequently I suspect it will 
be 100% ignored. And folks will continue to muddle along just fine. :) 

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#207199

Gene Heskett, on 2019-04-09 :
> On Tuesday 09 April 2019 09:38:43 Vincent Lefevre wrote:
> > This is unrelated to your issue, but note that the correct TZ string
> > for UTC is "UTC0", not "UTC". See
> >
> > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.htm
> > l
>
> Yikes. Can that be actually put into English?

Good Day Gene,

For general use, you might prefer to stick to a geographical
location, instead of a time zone code.  This way you don't have
to wonder if you are either in Daylight savings or not, if your
offset is -4 or +4, etc.  Maintainers of `tzdata` handle that
for you (a great "Thank You!" to these people by the way).

Usually, people in my neighborhood would use the equivalent of
the following, for instance:

	$ TZ=Europe/Paris LC_TIME=fr_FR.UTF-8 date
	mardi 9 avril 2019, 20:14:07 (UTC+0200)

Perhaps you will prefer setting a location nearer to yourself:

	$ TZ=America/New_York LC_TIME=en_US.UTF-8 date
	Tue 09 Apr 2019 02:20:00 PM EDT

The output may differ depending on you operating system level,
given Reco's observations.  Feel free to have à look at
/usr/share/zoneinfo/, to have an idea of the available
locations.

Kind Regards,
-- 
Étienne Mollier <etienne.mollier@mailoo.org>

[toc] | [prev] | [next] | [standalone]

#207212

On 2019-04-09, Étienne Mollier <etienne.mollier@mailoo.org> wrote:
>
> The output may differ depending on you operating system level,
> given Reco's observations.  Feel free to have à look at
> /usr/share/zoneinfo/, to have an idea of the available
> locations.

I took a look.

I was confused to note the presence of the UCT zone. UCT? Shouldn't that
be UTC?  But the latter zone proves to be a symlink to the former.

Then there's the GMT0, GMT-0, and GMT+0 zones, all symlinks to plain old
venerable GMT, which kind of makes sense, I guess, zero being what it is.

Anyway, it's getting late.

Out.

> Kind Regards,

[toc] | [prev] | [next] | [standalone]

#207217

On Tue 09 Apr 2019 at 20:07:37 (-0000), Curt wrote:
> On 2019-04-09, Étienne Mollier <etienne.mollier@mailoo.org> wrote:
> >
> > The output may differ depending on you operating system level,
> > given Reco's observations.  Feel free to have à look at
> > /usr/share/zoneinfo/, to have an idea of the available
> > locations.
> 
> I took a look.
> 
> I was confused to note the presence of the UCT zone. UCT? Shouldn't that
> be UTC?  But the latter zone proves to be a symlink to the former.

I imagine it gets called Universal Coordinated Time (whereas I always
pronounce it "you-tee-see"). My rationalisation would be that it's
Coordinated Time (so was GMT) that has been agreed as Universal.
If it was already Universal Time, it wouldn't need to be Coordinated.
So I prefer it to Wiki's Coordinated Universal Time. Anyway, cut time
is a musical concept. UTC is of course a French acronym.

But I don't have symlinks: they're separate files, thus preserving the
name of the zone for those who still use it. I think that officially
it has migrated to the fictitous continent of landfill called "Etc".

> Then there's the GMT0, GMT-0, and GMT+0 zones, all symlinks to plain old
> venerable GMT, which kind of makes sense, I guess, zero being what it is.

Yes, and a load of GMT+x stuff which suffers the same way as UTC+x:
you end up with the name GMT applied to times that aren't GMT.

> Anyway, it's getting late.

Not here: it's barely teatime.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#207200

On Tue 09 Apr 2019 at 14:03:08 (-0400), Gene Heskett wrote:
> On Tuesday 09 April 2019 09:38:43 Vincent Lefevre wrote:
> > On 2019-04-08 18:26:23 +0300, Reco wrote:
> > > stretch$ TZ=UTC date
> > > Mon Apr  8 15:22:02 UTC 2019
> > > buster$ TZ=UTC date
> > > Mon 08 Apr 2019 03:22:04 PM UTC
> >
> > This is unrelated to your issue, but note that the correct TZ string
> > for UTC is "UTC0", not "UTC". See
> >
> >  
> > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.htm
> >l
> 
> Yikes. Can that be actually put into English?
> 
> I've read thru it, and the only thing I can come away is that 'if UTC, 
> then offset is required, and it can be anything from -23 to +23, 
> including your example 0 meaning no offset from UTC.
> 
> As it now reads, theres a ton of ambiguity that needs further 
> clarification.

I'd agree. I really can't see how you can use UTC6 as a timezone
though it makes sense as an offset. But in that case, UTC is UTC,
and the zero is just tautological.

We avoided the problem when I went to sea by using the letter codes,
Z(ulu), A(lpha), B(ravo) etc. because there are no civil timezones,
daylight savings times or anything else. 

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#207202

On 4/9/19 8:39 PM, David Wright wrote:
> We avoided the problem when I went to sea by using the letter codes,
> Z(ulu), A(lpha), B(ravo) etc. because there are no civil timezones,
> daylight savings times or anything else. 

You mean, like this ?

	$ TZ=Zulu date
	Tue Apr  9 18:46:20 UTC 2019

:)
-- 
Étienne Mollier <etienne.mollier@mailoo.org>

[toc] | [prev] | [next] | [standalone]

#207210

On Tue 09 Apr 2019 at 20:46:53 (+0200), Étienne Mollier wrote:
> On 4/9/19 8:39 PM, David Wright wrote:
> > We avoided the problem when I went to sea by using the letter codes,
> > Z(ulu), A(lpha), B(ravo) etc. because there are no civil timezones,
> > daylight savings times or anything else. 
> 
> You mean, like this ?
> 
> 	$ TZ=Zulu date
> 	Tue Apr  9 18:46:20 UTC 2019

Yes, but only Zulu works here, not Z, nor all the rest.
But we were using it as the shortest unambiguous representation of
the timezone we were currently sailing in, suitable even for drunks
dozing off in the middle of the Middle Watch to get right. The last
thing you want is people trying to do timezone conversions in the
middle of the night. The confusion arises because the scientific
clocks displayed UTC whereas the scientists and crew worked in
shipboard/local time.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#207209

On Tuesday 09 April 2019 14:39:19 David Wright wrote:

> On Tue 09 Apr 2019 at 14:03:08 (-0400), Gene Heskett wrote:
> > On Tuesday 09 April 2019 09:38:43 Vincent Lefevre wrote:
> > > On 2019-04-08 18:26:23 +0300, Reco wrote:
> > > > stretch$ TZ=UTC date
> > > > Mon Apr  8 15:22:02 UTC 2019
> > > > buster$ TZ=UTC date
> > > > Mon 08 Apr 2019 03:22:04 PM UTC
> > >
> > > This is unrelated to your issue, but note that the correct TZ
> > > string for UTC is "UTC0", not "UTC". See
> > >
> > >
> > > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08
> > >.htm l
> >
> > Yikes. Can that be actually put into English?
> >
> > I've read thru it, and the only thing I can come away is that 'if
> > UTC, then offset is required, and it can be anything from -23 to
> > +23, including your example 0 meaning no offset from UTC.
> >
> > As it now reads, theres a ton of ambiguity that needs further
> > clarification.
>
> I'd agree. I really can't see how you can use UTC6 as a timezone
> though it makes sense as an offset. But in that case, UTC is UTC,
> and the zero is just tautological.
>
> We avoided the problem when I went to sea by using the letter codes,
> Z(ulu), A(lpha), B(ravo) etc. because there are no civil timezones,
> daylight savings times or anything else.
>
> Cheers,
> David.

I've at times wondered about that, but I never did any military service, 
seems the were wanting cannon targets for Korea. I made a 98 on the AFQT 
in '53 or so, which automatically got me 4F'd. Obviously they didn't 
want anyone who could think. The next best score in just under 140 boys 
that took that test that day was 36.  He of course would take orders. 
They didn't have time to mess with somebody who would question orders. 
60+ years later I can say I've had a good ride thru several technical 
fields. I have a list of BTDT's that not many could match.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web