T.Rob, 2038 I will (hopefully) have went into retirement ;-)
Regards Hubert > -----Ursprüngliche Nachricht----- > Von: MQSeries List <[email protected]> > Gesendet: 06.02.07 05:43:44 > An: [email protected] > Betreff: Re: This DST change.... > Dan, > > The problem is largely with date arithmetic. If we convert a date/time to > epoch seconds (the native format in Unix) and add some number of seconds > then convert back we can derive a new date/time. Logic says that if we > add 3600 seconds to this value we should get a new date/time that is one > hour different from the first. But DST leaves discontinuities in the > timeline such that adding 3600 seconds in some cases gives us exactly the > same derived date/time and in the other case it gives us a two hour > difference instead of a one hour difference. > > If we keep a one-dimensional array with the start/end dates for DST we can > correct date/time calculations for DST in the current year. This is what > Windows does. This is also accurate historically as far back as the DST > dates remain constant. After that it breaks *unless* we maintain a table > with rows of historical DST changes. This is what Java does. The problem > with Java is that the table of changes can only be updated with a patch or > upgrade. Unless it is updated, any date arithmetic which spans the DST > change dates breaks. This includes both historical date/time calculations > which will occur in a few months, but also forward-looking date/time > calculations which are occurring now. > > So why do we care? Can't you just store all times in GMT or epoch > seconds? Well, yes and no. There are many cases in which LOCAL time > values are used. The big example you hear about is transportation - > freight shipping and passenger travel. It would be a bummer to have two > trains on the same track at the same time for instance. Or two planes > sharing the same space and time, for that matter. Schedules have to be > coordinated across time zones and even across boundaries between observed > and non-observed DST in the *same* time zone. > > And if you like that, wait until January 19th 2038 when time will overflow > on 32-bit Unix systems. But that's 31 years from now and we'll DEFINITELY > have updated to 64-bit time values by then, right? RIGHT? > > In the meantime, have a read here: http://en.wikipedia.org/wiki/Unix_time > and in particular scroll down to 32-bit overflow section. > There is also an interesting DST article here: > http://en.wikipedia.org/wiki/Daylight_saving_time > > -- T.Rob > > T.Robert Wyatt, Consulting IT Specialist > IBM Software Services for Websphere > email: [EMAIL PROTECTED] > 704-719-2107 Access Line > > > MQSeries List <[email protected]> wrote on 02/05/2007 > 04:44:52 PM: > > > Hi.... > > > > I have searched around for an answer to this question and I cannot > > find anything that seems specific so I figured I would pop it up on > > here. What is there about this particular DST change that has so > > many people worried?? In particaulr, why is IBM coming out with > > specific fixes for this? We have these DST changes every year, > > albeit this one is earlier than normal but I do not see when it > > happens as mattering. Have I just had my head buried in the sand in > > the past and did not know that this "concern" happens every year or > > is there something specific about this DST change that warrrants all > > of the attrention? > > > > Thanks.... > > Dan > > To unsubscribe, write to [EMAIL PROTECTED] and, > in the message body (not the subject), write: SIGNOFF MQSERIES > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html > -- Hubert Kleinmanns Beratung / Schulung / Projektleitung Tel.: +49 (0) 60 78 / 7 12 21 Fax: +49 (0) 60 78 / 7 12 25 Mobil: +49 (0) 178 / 6 97 22 54 To unsubscribe, write to [EMAIL PROTECTED] and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
