Here's my 2 cents.
My understanding is that the problem is not with the current date but
with stored dates.
Many applications store a dates and datetimes as offsets from some
reference time. For instance, the number of seconds after or before a
reference date. When stored, the datetime is a pile of seconds. When
displayed, the client application makes the "local" correction. Based on
the offset, it determines the correct datetime in UT (Universal Time),
and then adjusts for local time zone.
This approach makes it easy to build an application that works between
time zones. The West Coast office shows times in Pacific Time, the East
Coast office shows times in Eastern Time. Both are stored effectively as
an offset to UT. West and East can schedule a phone conference, and each
views the UT appointment in "local" time.
Because stored times need to be adjusted by the client, it makes a
difference whether the client thinks a date is operating under daylight
time or not. During Standard time, Pacific Time is 8 hours offset from
Universal Time. During Daylight Time, the offset is 7 hours. Thus, a
correctly stored datetime will display differently on different clients.
At work, I updated my Windows machine today, and sure enough, I looked
at an Outlook weekly appointment for next week that should show for 9am.
It shows as 10am. For the next three weeks, the appointment shows at
10am. Then starting in April, the appointment shows correctly again --
9am for the remaining weeks of the year. Even the last week in October
shows correctly, suggesting to me that the MS patch fixed only the March
dates.
This 1-hour-off problem would affect any application that stores dates
in this manner. It is my understanding that this is the Java approach,
so I would expect that Java applications have similar issues. I expect
that the problem would exist in any Unix application that adopted this
approach. I am not a Unix expert, so I can't cite particulars. Perhaps,
some of the other EUGLUG members can shed light here.
Then you face the EECO principle (Equal Errors Cancel Out). If all
clients are in error together, the correct results may be displayed.
However, one client is patched and another is not, they will disagree on
displayed times, just like the the West and East Coast offices.
Regards,
Carl Cole
Michael Miller wrote:
This is how I understand it from a Sysadmin view.
You would think that if you use a date() system call. In PHP you
would use string date ( string $format [, int $timestamp] ). So if
that is using the X Unix like OS epoch to resolve the date. Then you
check to make sure your systems spits this example output..
usr/share/zoneinfo/PST8PDT Sun Mar 11 09:59:59 2007 UTC = Sun Mar 11
01:59:59 2007 PST isdst=0 gmtoff=-28800
/usr/share/zoneinfo/PST8PDT Sun Mar 11 10:00:00 2007 UTC = Sun Mar 11
03:00:00 2007 PDT isdst=1 gmtoff=-25200
/usr/share/zoneinfo/PST8PDT Sun Nov 4 08:59:59 2007 UTC = Sun Nov 4
01:59:59 2007 PDT isdst=1 gmtoff=-25200
/usr/share/zoneinfo/PST8PDT Sun Nov 4 09:00:00 2007 UTC = Sun Nov 4
01:00:00 2007 PST isdst=0 gmtoff=-28800
You should be fine. Now if your application is using some other
method to figure out what date is. I would say our screwed. Bob you
a senior level programmer, so let me know if I'm full of crap.
So the question I have is your Windows system patched? If so why is
the "meeting scheduling apps " not using a Windows API to pull the
date? ( If there is one ).
I think this is going to hit the health and medical people the most.
There is a massive amount of embedded equipment in the medical field.
From the telemetry systems that monitor vital signs, all the way down
to the pharmacy prescription dispensers. Another area that will be
hit unless they started thinking about this back in 2005 are the
billing systems. It may not be that much of a mess but I would expect
your bills to be late and or some automated call telling you that your
behind on some payment. Then again if Bob is having problems with his
Windows based meeting app. I would expect Windows cash registers and
ATM machines to have problems. So I would get some cash out before
the time switch.
-Miller
_______________________________________________
EUGLUG mailing list
[email protected]
http://www.euglug.org/mailman/listinfo/euglug
_______________________________________________
EUGLUG mailing list
[email protected]
http://www.euglug.org/mailman/listinfo/euglug
