sendmail timestamp wrong after slewing hp-ux clock

[Jim Wallace]

Hi,

I used "date -a 3600" to slew/drift several customer machines system clocks, since we switched to BST here in the UK on Sunday. Each of these machines has the timezone set to GMT0.

emails sent from these servers to other machines now have the 'sent' time appearing an hour ahead.

I've checked in sendmail.cf and the "O TimeZoneSpec=" is not set to anything. (I've also done a stop/start on sendmail itself since the clock slewing)

I've also done an "echo "TEST"|sendmail -ODeliveryMethod=q " to queue up an email. When I go into the mail queue and look at the bigger of the two files for this email, all the timestamps in there are correct.

I've had one customer also check their mail relay box too, and they report correct time and also sat at GMT for timezone.

Suggestions would be most welcome.

Thanks,
Paul M

[Matti_Kurkela · Accepted solution]

The timezone setting "GMT0" says the local system time shall be equal to UTC time _all the time_, in every day of every year.

If your timezone uses the Daylight Saving Time/Summer Time convention, you must change your _timezone_ settings to account for this.

Slewing the system clock was incorrect: now the systems' idea of the UTC time is off by one hour. Among other things, the email protocols make heavy use of the UTC time (or the local time + the UTC offset, which amounts to the same thing).

The UTC time is standardized to never switch to DST/Summer Time. This is one of the reasons it's useful as "universal" timescale.

In UK, your timezone should be set to "GMT0BST". When your timezone setting includes the Summer Time specifier, the system automatically uses the time transition rules for your timezone, listed in /usr/lib/tztab.

All Unix systems handle all time values internally in UTC timezone: the same is true for all major databases and all properly-designed applications. All user input is internally converted to UTC timezone before processing. When time values are included in the system output, they are likewise converted back to the local timezone (including the Summer Time convention)... or to another timezone, if so desired.

You should now slew the system clocks back 1 hour, so that the systems will again have correct UTC time information. Then you should stop the applications, change the default timezone setting in /etc/TIMEZONE, logout & login so that your environment includes the new setting, then restart the applications.

Once you've made this change, your systems will handle all the future Summer/Winter time shifts automatically. The instant shift is possible precisely because the system always uses UTC time internally. For the system, the switch between Summer and Winter time does not change the system clock at all: it only changes the way the time values are presented to humans.

> When I go into the mail queue and look at the bigger of the two files for this email, all the timestamps in there are correct.

I bet you're only looking at the time values, not at the timezone specifiers associated with the timestamps.

When email timestamps may use local time, they should always be accompanied with timezone specifiers. For example, before the transition to BST, the timestamp for a message sent a week ago at 11:00 a.m. would have been ...11:00:00 +0000.

Now, after transition to BST, a message sent today at 11:00 a.m. would have a timestamp ...11:00:00 +0100.

To produce the email timezone specifiers correctly, the system needs correct information about the local timezone, including the Winter/Summer time state.

MK

[Jim Wallace]

Many thanks Matti,

Unfortunately we do not want systems automatically jumping forward and backwards for change of GMT/BST so are stuck with this.

I guess the issue is that the mail sent out indicates GMT against it and the mail relays on other hosts are correcting for this and hence we see an hour being added on to the 'sent' time of the email. (I think this must be the case because when I email a userid on the same host, the timestamp remains correct).