adding commands to installer image

Larry Brigman larry.brigman at gmail.com
Thu Aug 6 03:37:08 UTC 2009


On Wed, Aug 5, 2009 at 8:12 PM, Bryan J Smith<bjs at redhat.com> wrote:
> On Thu, 2009-08-06 at 10:53 +0800, John Summerfield wrote:
>> I have regularly seen files timestamped  "in the future" after
>> installation, and I don't do anything extraordinary. I always run my
>> computers' clocks on local time.
>> I have always assumed, "Stupid Americans, they always think the rest of
>> the world does things their way."
>
> Actually, running the RTC on localtime is very much a legacy Microsoft
> limitation / attitude.  So the allegedly "stupid American way" is
> actually to run your RTC on localtime.
>
> Open systems have traditionally run their RTC on UTC.  The idea is that
> you offset everything, system, application, user, etc... localtime, from
> UTC, which is the RTC.
>
> Here's the general rule of thumb ...
> - All RTCs and most "real-time" stamps should be made in UTC
> - Events should be made in the specific timezone they are local to
>
> Remember, timezones change, and even timezone rules (offsets) change.
> UTC does not.  Hence why RTCs should be UTC always, and most real-time
> events stamped on UTC.
OK.  I don't run the RTC on localtime.  The vendor/manufacture ships the
system configured with the RTC set to some localtime (manufacture site).

>
> Events, on the other hand, will always be in localtime, so they should
> always be stored in localtime with the reference timezone.  Again,
> because timezones and timezone rules change, offsets should be made from
> that stored localtime.  E.g., calendar events.

Understood.  The first time the box get a connection to a NTP server,
the RTC gets
set to UTC.


I'm just trying to find a way to get the RTC close to UTC (within
about a minute) without manual intervention during the kickstart prior
to package installation if I have a vaild/active network
configuration.




More information about the Kickstart-list mailing list