TZ=

[Dave La Mar]

Note that I am fully aware of caljd.sh and put it to good use.

My inquiry is concerning the failure of TZ= following the time change this past weekend.

We recently upgraded a couple of machines from 11.0 to 11.11 and noticed that 11.11 came

with the new tz table for the 2007 date changes for time.

On our 11.0 machines TZ=PST8PDT+24 date +%A wields yesterday's full name day of the week.

It had worked on the 11.11 machines as well until this past weekend.

Now, I am not advocating using TZ= as I have described. I am simply curious as to whay this would
stop working.

Of course if I set the offset to 24, it appears to wroke as previously noted,

i.e. TZ=PST24PDT date +%A.

Has anyone encountered this?

Regards,

DL

[James R. Ferguson]

Hi Dave:

The use of the following is commonly seen to compute tomorrow's date:

# TZ=GMT-24 date +%m/%d/%y

...and correspondingly, yesterdays's date:

# TZ=GMT+24 date +%m/%d/%y

Eurpopeans,living around the Prime Meridian are the "lucky" ones who can use +-24 hours to exactly compute yesterday or tommorrow *including* the correct time.

As noted by the man pages for 'environ(5)', the offset is the value that must be added to local time to arrive at UTC (GMT). The offset takes the format hh[:mm[:ss]]
where 'hh' is any value from 0 through 23. The optional minutes (mm) and seconds (ss) fields are a value from 0 through 59. The hour field is required. If offset is preceded by a -, the time zone is east of the Prime Meridian. A + preceding offset indicates that the time is one that is west of the Prime Meridian.

Thus, you should beware when trying to perform such trickery as you describe.

A rigorous, safe method to find the day as it was 24-hours ago in your local timezone is:

# perl -MPOSIX -le 'print strftime(%A,localtime(time-(24*60*60)))'

You can use any of the 'strftime(3C)' formatting directives you want.

Regards!

...JRF...

[A. Clay Stephenson]

You have been relying upon a feature that works more or less by accident --- and not across all flavors of UNIX. Using Perl or (caljd.sh) is a much more robust and portable solution. A careful reading of the environ man page explains that the offset must be in the range of 0-23 and you are violating that. It just so happens that your trick works in a few timezones.

[Dave La Mar]

Thank you James. You obviously read my question and are explicit in the explanation.

As I stated "I do not condone using this method for date calculations."

My curiosity is in why it changed in execution.

Thank you for the input.

A. Clay -
No question in the value of using caljd.sh. (For those forum'ers that have not used it, it is strongly suggested to investigate.)
My question was straight forward and granted, yes, any use of this in the past may have been pure luck in results. Thus my insistance on not advocating it.

Hopefully, further input on this will be even more enlightening on the change in execution.

Regards,

-dl

[Dave La Mar]

As I close this thread allow me to reiterate; at no time should anyone consider
the TZ= information a viable means of date/time calculation.

I can only assume that the lack of additional input is a confirmation of the above.

Thank you James and A. Clay for at least attempting a reasonable explanation for
what I was asking.

Regards,

-dl