root@S9:>uname -a
SunOS 5.9 Generic_Virtual sun4u sparc SUNW,Sun-Blade-T6340
This Sunday, November 4th, Daylight Time will take effect at 2:00 am CST. Time will roll back (1) hour. We need the to maintain/keep the Time unchanged until 8:00 am CST.
> This Sunday, November 4th, Daylight Time will take effect at 2:00 am CST.
> Time will roll back (1) hour. We need the to maintain/keep the Time
> unchanged until 8:00 am CST.
> Any ideas?
Why in the world would you need to do this?
You do understand that the system really runs in UTC, don't you.
If you really, really, really need to do this, edit the timezone file.
> > This Sunday, November 4th, Daylight Time will take effect at 2:00 am CST.
> > Time will roll back (1) hour. We need the to maintain/keep the Time
> > unchanged until 8:00 am CST.
> > Any ideas?
> Why in the world would you need to do this?
> You do understand that the system really runs in UTC, don't you.
> If you really, really, really need to do this, edit the timezone file.
Is this as simple as commenting out this entry in cron:
root@S9:>crontab -l
#ident "@(#)root 1.20 01/11/06 SMI"
#
# The root crontab should be used to perform accounting data collection.
#
# The rtc command is run to adjust the real time clock if and when
# daylight savings time changes.
#
10 3 * * * /usr/sbin/logadm
15 3 * * 0 /usr/lib/fs/nfs/nfsfind
1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1
Dariusz Dolecki <dariusz.dole...@gmail.com> wrote:
> On Friday, November 2, 2012 6:16:02 PM UTC-5, ji...@specsol.spam.sux.com wrote:
>> Dariusz Dolecki <dariusz.dole...@gmail.com> wrote:
>> If you really, really, really need to do this, edit the timezone file.
> Is this as simple as commenting out this entry in cron:
> root@S9:>crontab -l
> #ident "@(#)root 1.20 01/11/06 SMI"
> #
> # The root crontab should be used to perform accounting data collection.
> #
> # The rtc command is run to adjust the real time clock if and when
> # daylight savings time changes.
> #
> 10 3 * * * /usr/sbin/logadm
> 15 3 * * 0 /usr/lib/fs/nfs/nfsfind
> 1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1
Dariusz Dolecki <dariusz.dole...@gmail.com> wrote:
>> man zoneinfo
> root@S9:>man zoneinfo
> No manual entry for zoneinfo.
> root@S9:>
> This is Solaris 9 and I am not changing the time zone.
> Can anyone else please help
# man zoneinfo
File Formats zoneinfo(4)
NAME
zoneinfo - timezone information
DESCRIPTION
For notes regarding the zoneinfo timezones, see
/usr/share/lib/zoneinfo/src/README.
SunOS 5.9 Last change: 21 Jun 1999 1
When you read /usr/share/lib/zoneinfo/src/README, take note of the "For
more information see..." note at the end of it.
Summary:
You need to edit the source file for your timezone with your custom
rule, run the time zone compiler to rebuild the files that are actually
used by the system, then reboot to ensure everything picks up the new rules.
After your "magic date" has passed, reverse everything you did.
Dariusz Dolecki <dariusz.dole...@gmail.com> wrote:
> root@S9:>man zoneinfo
> No manual entry for zoneinfo.
> root@S9:>
> This is Solaris 9 and I am not changing the time zone.
> Can anyone else please help
I forgot to mention two things:
1. Either you don't have man pages installed or your MANPATH is hosed.
2. You never did say why you think you need to do this; the only thing
this will effect is what the system will return as the local time for
things done DURING AND ONLY DURING your artificial period. All the things
like timestamps on files are in UTC.
Dariusz Dolecki <dariusz.dole...@gmail.com> writes:
>root@S9:>uname -a
>SunOS 5.9 Generic_Virtual sun4u sparc SUNW,Sun-Blade-T6340
>This Sunday, November 4th, Daylight Time will take effect at 2:00 am CST. Time will roll back (1) hour. We need the to maintain/keep the Time unchanged until 8:00 am CST.
>Any ideas?
What the other guy is saying is if you don't want daylight savings
time effects, then you probably should run in timezone UTC, so there
are no daylight saving time effects.
Or, you can edit your timezone info to mess with when daylight savings happen
(assuming you have patched your system so that it actually knows the
new daylight savings date as opposed to when Solaris 9 actually was a
shipping product..)
BUT -- you should understand unix time keeping a bit better.
Unix timestamps *everything* in seconds since the unix epoch. This is
not affected by daylight savings time, (other than places that only store a human readable form of the time, such as syslog entries).
So, if you have a program that is chugging away, say right now, it
thinks the time() is 1351920086. If for example, daylight savings
kicked in right now, the next time() is 1351920087, even though
daylight savings just kicked in, it still just keeps counting the
seconds since the epoch.
It is only when 1351920086 is converted back to a human readable time,
that any daylight savings effects come into play, and depending on
your timezone setting, following the arcane rules in the zoneinfo database,
will you get a result in CDT or CST or whatever timezone you are in.
Internally, all your programs count time correct, there are only
effects when and only when these programs print time output in human
readable format.
But of course, running in UTC never has any day light savings time
kick in, so there is never any issue running with timezone in UTC.
> This Sunday, November 4th, Daylight Time will take effect at 2:00 am CST. Time will roll back (1) hour. We need the to maintain/keep the Time unchanged until 8:00 am CST.
> Any ideas?
Okay, I am finding it hard to accept that changing the TZ will resolve the issue. This is why, and I apologize for not having introduced you to the dynamics of the issue:
The app guy don't want the time to change on the system until 8:00 AM so it does not affect the delivery truck checkout time reporting. There are thousands of delivery trucks and I think they all operate on the CDT TZ.
I am still assuming if I comment that script till 8AM 11/4 everything will be fine.
>> This Sunday, November 4th, Daylight Time will take effect at 2:00 am.
>> CST. Time will roll back (1) hour. We need the to maintain/keep the.
>> Time unchanged until 8:00 am CST.
>> Any ideas?
> Okay, I am finding it hard to accept that changing the TZ will resolve.
> the issue. This is why, and I apologize for not having introduced you to.
> the dynamics of the issue:
> The app guy don't want the time to change on the system until 8:00 AM so.
> it does not affect the delivery truck checkout time reporting. There are.
> thousands of delivery trucks and I think they all operate on the CDT TZ.
> I am still assuming if I comment that script till 8AM 11/4 everything.
> will be fine.
> Please advise.
I told you what you have to do and the time on the system does NOT change.
The system is running in UTC and it is the rules in the timezone files that
cause the system to display a time that is in UTC in local time.
You have to change the source to your timezone rules, compile the source, and
reboot the system.
After the period is over, reverse everything.
Also, whether or not this will have any effect on delivery truck checkout
time reporting in the long term depends on how this is implemented.
Further, why would "thousands" of trucks be operating on the wrong time?
As far as "that script" goes, if you are talking about the rtc entry in
cron, that just effects the hardware clock, which is only referenced at
boot time.
