My original post:
> If anybody out there is using there systems in a "real time enviroment", and
> your running some kind of trending application eg monitoring process variants
> over time, I would like to know how your systems deal with timezone changes
> like daylight savings.
> eg Your displaying a graphical trend just prior to the clocks going back for
> daylight saving. The trend starts at say 11 pm but at midnight the clock
> goes back to 11 pm.
> This causes quite a problem on a VAX running some off the shelf software. IF
> UNIXsystems/applications handle this better, then a UNIX box may find its way
> into this production area.
> Any ideas, opinions or examples would be appreciated.
Thanks to all who responded!
PS This was not an exercise in knocking VMS ;-), just a querry into how UNIX
handles this problem - broadening my understanding.
I'm not sure that I 100% understand what you are asking, but this _is_ the
Internet, sooooo.... :-)
Why not just stick to a single timezone - i.e. always use AEST, or
even easier UTC, and you will get a nice continuous timeline. As long
as the underlying time assumption is made clear most people/computers
will cope just fine with this. It may mean hacking your timestamps somehow
if it just uses the local system clock. Under Unix (and probably under
VMS) there are C functions for converting system time to local time/UTC
and back and forth.
Clearly timetrends make no sense if you start to include daylight savings,
as your functions become bivalued for an hour. Which is more meaningful ?
If you are looking for trends like daytime vs nighttime values then
don't use time, but the altitude of the Sun.... 1/2 * :-)
Coming from an astronomical background I'm quite used to this time problem -
we use Julian date (days since about 4000 BC) with time during the day being
shown with decimals. Bingo - a standard timezone for everybody around the
world ! :-)
Hope that gives you some ideas .... ?
Cheers,
Markus
Markus Buchhorn, Parallel Computing Research Facility
email = markus@octavia.anu.edu.au snail = CISR, I Block, OAA, ANU
Australian National University, Canberra, 0200 , Australia.
[International = +61 6, Australia = 06] [Phone = 2492930, Fax = 2490747]
----------------------------------------------------------------------------
> eg Your displaying a graphical trend just prior to the clocks going back for
> daylight saving. The trend starts at say 11 pm but at midnight the clock
> goes back to 11 pm.
>
On a UNIX system, the time itself never changes, only the timezone. So
as long as the application uses the 'absolute time' (which normally gets
converted to what you see based on the current timezone), then
everything should work OK. Of course the application would have to be
'DST aware', to present the data with a time axis something like the
following:
|
+-----|-----|-----|-----|-----|-----|-----|-----|-----|--->
9pm 10pm 11pm 11pm 12pm 1am 2am 2am 4am
<-- daylight time -----> <---- standard time ---------->
Hope this helps,
Ray Brownrigg ray@isor.vuw.ac.nz
---------------------------------------------------------------------------
The traditional method is to use seconds since Jan 1, 1970 GMT for
anything real (like the times in a database) and converting the time
displayed to local time.
That only solves part of your problem of course but does keep
the programmers clear about what the time data REALLY is and is
consistent all over the planet.
For clock synchronization xntpd seems to work well; that's what the
folks tracking satellites around here use.
---Dave Fetrow mail: SC-32 (Biostat), University of Washington, Seattle, Wa. 98195 USA phone: (206)-685-2376
--------------------------------------------------------------------------
Unix Systems are *supposed* to handle Time in two Notions: local (your Timezone) and "real" (using something effectively being UTC, i.e., no DST). If the Software is correctly written to use the latter if Time Travel is undesirable ;-), no Problem; e.g., the SMTP Mail Transfer Protocol all Unixes have built in is known to barf if two Hosts have deviating Times, yet works without this Kind of Flaw with worldwide Connections and Bazillions of Mails every Day. Lots of homebrew Scripts, OTOH, can have serious Difficulties with DST (because they usually get their Time by simply calling 'date', which returns the local Time Zone). However, large Programs tend to be written in some higher Programming Language, so it is probable that the basic Data Types of the appropriate Libraries get used - which, in Turn, are based on "the right" Time (and given as a long Integer telling the Number of Seconds elapsed from the famous "Epoch" ;-).
A Problem you didn't mention is that the Sysadmin might try to adjust a skewed System Clock. Modern Unixes provide a special System Call so that the Adjustment doesn't get applied at once but by changing the Clock Speed until the specified Offset is reached.
Here's the appropriate Section of the date Manpage (er, HELP Lib Module ;-) of my SunOS 4.1.3_U1B System if your Bosses want to see some Confir- mation:
OPTIONS -u Display the date in GMT (universal time). The system operates in GMT; date normally takes care of the conversion to and from local standard and daylight time. -u may also be used to set GMT time.
-a [-]sss.fff Using the adjtime(2) system call, tell the system to slowly adjust the time by sss.fff seconds (fff represents fractions of a second). This adjustment can be positive or negative. The system's clock will be sped up or slowed down until it has drifted by the number of seconds specified.
Regards, J. Bern -- __/\_____________________________________________ ___________________________ / \ \ / /\ / J. \ EMail: bern@Uni-Trier.DE (7 Bit only!) X Ham Call Sign: DD0KZ / \ \Bern/ bern@TI.Uni-Trier.DE (OW Mails OK) / \ Public PGP & RIPEM/ \ / \ / P. O. Box 1203, 54202 Trier, Germany / \ SIG Keys via finger \/ __\/___________________________________________/ EOF \_________________________
---------------------------------------------------------------------------
It's no problem in UNIX. The UNIX system clock keeps time in seconds since January 1, 1970 00:00:00 GMT; it doesn't know or care about timezones or daylight savings time (there is a system-wide default timezone, but its use is not forced on you; most kernel time keeping operations ignore it).
The timezone and daylight savings time are typically handled by C library functions which are used only when the time is to be displayed in a human-readable form. In your case, the trend analysis program should track time internally using the standard UNIX GMT-based representation, and only convert to the local time zone representation for the purpose of labeling the time axis of the graph.
The only UNIX program I know of that has a problem with daylight savings time changes is cron, which executes programs at scheduled times according to the system's default time zone. A program scheduled to be run at, say, 2:30 AM, will be skipped on the day that daylight savings time starts and run twice on the day that it ends (here, in the US, daylight savings time changes take effect at 2 AM). -- Michael T. Sullivan | email: mike@trdlnk.com TradeLink L.L.C. | voice: +1 312 408 2599 175 W. Jackson, Suite A1235 | fax: +1 312 939 2531 Chicago, Illinois 60604 USA |
---------------------------------------------------------------------------
The off-the-shelf software seems to be called "VMS", i'm sure. I never had a problem with VAXen running BSD or Ultrix.
>UNIXsystems/applications handle this better, then a UNIX box may find its way >into this production area.
unix clocks run on UTC (Universal Time Coordinated). It's the date-displaying routines/programs that do the correction for local time zone or daylight savings time.
most modern unix systems have a tool (such as "zic") that lets you specify the exact algorithm. It will give correct results when computing, for example, the local time 126230400 seconds (four years) ago, even if the rules have changed since then.
south australia went thru three changes in the daylight savings time algorithm since 1970, if the "zic" input file:
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule AS 1971 max - Oct lastSun 2:00 1:00 - Rule AS 1972 1985 - Mar Sun>=1 3:00 0 - Rule AS 1986 1989 - Mar Sun>=15 3:00 0 - Rule AS 1990 max even Mar Sun>=22 3:00 0 - Rule AS 1990 max odd Mar Sun>=1 3:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/South 9:30 AS CST
can be trusted.
+----------- Andi Karrer, Institute for Electronics, ETH Zuerich, Switzerland karrer@bernina.ethz.ch - CH stands for Calvin & Hobbs, the most influential Swiss religion <2n04i5$44j@hebron.connected.com>
----------------------------------------------------------------------------
In article <9408030244.AA19732@lpdwhy.bhp.com.au> you wrote: : eg Your displaying a graphical trend just prior to the clocks going back for : daylight saving. The trend starts at say 11 pm but at midnight the clock : goes back to 11 pm.
I don't have any direct experience in this area, but I can't believe that any well written unix code would have a problem. Unix stores times internally as seconds from Midnight, January 1st, 1970 GMT. All times are manipulated, compared, etc, as big integers which are time-zone (and even calendar) independant. Then when you actually want to display a date or time you convert to
"Wed Aug 3 07:43:15 EDT 1994"
or
"3rd day, 10th moon, year of the screaming bat"
or whatever you want. The way that you choose to represent the time shouldn't affect the program.
Of course you may see some strange axis labels on your graph:
2200 2300 0000 0000 0100
or
00:40 00:50 00:00 00:10 00:20
I don't know how Vaxen store time internally, but it sounds like you just ran into a bug in the program you are using - whoever wrote it just didn't realize that a graph could cross a timezone change.
------------------------------------- / ----------------------------> Chip
_____________________________________________________________________________
_real_ computers (i.e. all unix boxes) store everything in gmt, and handle the conversion to DST in the display!!
Greg.
----------------------------------------------------------------------------
The only thing I can think of is to always use GMT. Supposedly the clock on Suns counts time as GMT and your environment variables and configurations convert it to whatever your offset from GMT is.
Bert
-- David Robson (ROBBO),BHP Information Technology, P.O.Box 21, Whyalla South Australia 5600, Ph: +61 86 404596 Fax:...404720, E-mail dave@lpdwhy.bhp.com.au "Life's battle's don't always go To the stronger or faster man, But soon or late, the man who wins, IS THE MAN WHO THINKS HE CAN." -- Walter W. Wintle
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:07 CDT