- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: sendmail timestamp wrong after slewing hp-ux c...
Operating System - HP-UX
1753386
Members
5815
Online
108792
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-29-2011 05:18 AM
тАО03-29-2011 05:18 AM
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
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
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
Solved! Go to Solution.
2 REPLIES 2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-29-2011 06:24 AM
тАО03-29-2011 06:24 AM
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
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
MK
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-29-2011 06:47 AM
тАО03-29-2011 06:47 AM
Re: sendmail timestamp wrong after slewing hp-ux clock
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).
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).
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP