- tz - lists.iana.org

FW: Notes on 'timesub"
by Olson, Arthur David (NIH/NCI) [E] Jan. 15, 2009

Jan. 15, 2009

I'm forwarding this message from John Dlugosz, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. --ado From: John Dlugosz [mailto:JDlugosz@TradeStation.com] Sent: Thursday, January 15, 2009 12:40 To: tz(a)lecserver.nci.nih.gov Subject: Notes on 'timesub" The implementation of 'timesub' uses quite a bit of complex logic, approximations, and looping to do what can be done with a single expression. The part of the function that digests the number of days into y/m/d fields has been known since before computers as "Julian Day Number" and that can be harnessed directly simply by subtracting a constant for the Epoch base. Here is my version, which is not so digested into my own library that you can't follow the logic: void timezone_t::state::timesub ( const __time64_t t, // input time number const long offset, // added to time, but figures date from original (e.g. like a denormal value) ymd_hms& tmp // output ) const { // more complex than it needs to be! static const int JDayEpoch= Julian_day_number (ymd(EPOCH_YEAR, 1, 1)); int days_in_epoch = t / SECSPERDAY; int rem = t - days_in_epoch * SECSPERDAY; int corr= count_leap_seconds (JDayEpoch, JDayEpoch+days_in_epoch); tmp= Julian_day_number (JDayEpoch+days_in_epoch); tmp.set_normalized (hms(0,0,rem+offset - corr)); } In your code, the part I'm referring to is the middle. First it finds 'corr' for leap seconds, and afterwards it adds the seconds into the h/m/s possibly overflowing into the d/m/y. I have those in callable functions, but the approach is the same. It's just that the middle part, converting a number of seconds into y/m/d, is not as hard as you make it out to be. This is a direct implementation of the published formula, which involves no looping or successive approximations or peeling off each month individually: ymd Julian_day_number (int J) { const int j= J+32044; const int g= j / 146097; const int dg= j % 146097; const int c= (dg / 36524 + 1) * 3 / 4; const int dc= dg - c * 36524; const int b= dc / 1461; const int db= dc % 1461; const int a= (db/365+1) * 3 / 4; const int da= db - a * 365; const int y= g*400 + c*100 + b*4 + a; const int m= (da*5+308) / 153 - 2; const int d= da - (m+4) *153 / 5 + 122; return ymd (y-4800+(m+2)/12, (m+2)%12+1, d+1); } (The comment that it is (still) more complex than it needs to be is because the normalization code in my library can handle that directly, so I can just call existing code.) --John

1 0

Notes on 'timesub"
by John Dlugosz Jan. 15, 2009

Jan. 15, 2009

The implementation of 'timesub' uses quite a bit of complex logic, approximations, and looping to do what can be done with a single expression. The part of the function that digests the number of days into y/m/d fields has been known since before computers as "Julian Day Number" and that can be harnessed directly simply by subtracting a constant for the Epoch base. Here is my version, which is not so digested into my own library that you can't follow the logic: void timezone_t::state::timesub ( const __time64_t t, // input time number const long offset, // added to time, but figures date from original (e.g. like a denormal value) ymd_hms& tmp // output ) const { // more complex than it needs to be! static const int JDayEpoch= Julian_day_number (ymd(EPOCH_YEAR, 1, 1)); int days_in_epoch = t / SECSPERDAY; int rem = t - days_in_epoch * SECSPERDAY; int corr= count_leap_seconds (JDayEpoch, JDayEpoch+days_in_epoch); tmp= Julian_day_number (JDayEpoch+days_in_epoch); tmp.set_normalized (hms(0,0,rem+offset - corr)); } In your code, the part I'm referring to is the middle. First it finds 'corr' for leap seconds, and afterwards it adds the seconds into the h/m/s possibly overflowing into the d/m/y. I have those in callable functions, but the approach is the same. It's just that the middle part, converting a number of seconds into y/m/d, is not as hard as you make it out to be. This is a direct implementation of the published formula, which involves no looping or successive approximations or peeling off each month individually: ymd Julian_day_number (int J) { const int j= J+32044; const int g= j / 146097; const int dg= j % 146097; const int c= (dg / 36524 + 1) * 3 / 4; const int dc= dg - c * 36524; const int b= dc / 1461; const int db= dc % 1461; const int a= (db/365+1) * 3 / 4; const int da= db - a * 365; const int y= g*400 + c*100 + b*4 + a; const int m= (da*5+308) / 153 - 2; const int d= da - (m+4) *153 / 5 + 122; return ymd (y-4800+(m+2)/12, (m+2)%12+1, d+1); } (The comment that it is (still) more complex than it needs to be is because the normalization code in my library can handle that directly, so I can just call existing code.) --John

1 0

FW: timezone code - re-entrancy issue
by Olson, Arthur David (NIH/NCI) [E] Jan. 14, 2009

Jan. 14, 2009

I'm forwarding this message from John Dlugosz, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. --ado -----Original Message----- From: John Dlugosz [mailto:JDlugosz@TradeStation.com] Sent: Tuesday, January 06, 2009 7:36 To: tz(a)lecserver.nci.nih.gov Subject: timezone code - re-entrancy issue At the bottom of localsub, tzname[tmp->tm_isdst] = &sp->chars[ttisp->tt_abbrind]; I think this is to update the tzname string to the last time zone abbr. actually used in to produce the tm values. It is not re-entrant. This is called even by localtime_r, which may be changing the values even as another thread (who called plain localtime) is reading it. It also changes all the time as the "binary search" is being done by mktime. That violates the "behaves as if never called" rule, and putting it in a subroutine doesn't help there. Am I missing something? --John

4 11

What are tt_ttisstd and tt_ttisgmt for?
by John Dlugosz Jan. 14, 2009

Jan. 14, 2009

I thought I understood the comment in the file structure, ** one (char [4]) total correction after above ** tzh_ttisstdcnt (char)s indexed by type; if TRUE, transition ** time is standard time, if FALSE, ** transition time is wall clock time ** if absent, transition times are ** assumed to be wall clock time ** tzh_ttisgmtcnt (char)s indexed by type; if TRUE, transition ** time is UTC, if FALSE, ** transition time is local time ** if absent, transition times are ** assumed to be local time but, I don't see them being used the logic to search ats, or to adjust the ats values after loading. So if present in the data file they do nothing. In fact, I got rid of the TRUE's in one of the data files, and it did not make the program produce any different results. What am I missing?

1 0

IERS Message No. 141: New IERS Rapid Service/Prediction Center web site
by central_bureau＠iers.org Jan. 14, 2009

Jan. 14, 2009

************************************************************************ IERS Message No. 141 January 14, 2009 ************************************************************************ New IERS Rapid Service/Prediction Center web site Dear Colleagues, We would like to inform you that the IERS Rapid Service/Prediction Center's web site will be moving from http://maia.usno.navy.mil to http://www.usno.navy.mil/USNO/earth-orientation on 15 January 2009. Note that until the changeover date, the new web site can be found at http://199.211.133.90/USNO/earth-orientation. In addition to the change in address, the style of the web site has been changed to bring it into compliance with an institution-wide format. It is expected that attempting to access the old web site should result in a redirect to the new web site. We have been assured that this change in our web presence will in no way impact our e-mail or our ftp capabilities, i.e. ftp maia.usno.navy.mil will not be impacted. We would appreciate hearing any comments you have regarding the new web site. If you notice any unusual behavior, please let us know. Regards, William Wooden Director, IERS Rapid Service/Prediction Center ************************************************************************ IERS Messages are edited and distributed by the IERS Central Bureau. To subscribe or unsubscribe, please write to <central_bureau(a)iers.org>. Archives: http://www.iers.org/iers/publications/messages/ ************************************************************************

1 0

Meaning of 'goforward' flag ?
by John Dlugosz Jan. 13, 2009

Jan. 13, 2009

I think I understand how the ats array is extrapolated to dates beyond its end. The Gregorian calendar repeats every 400 years, so any rules based on weekdays and day of month numbers will have results that repeat. So, if the date is beyond the end of the array, subtract the smallest multiple of 400 years that produces a date that is within the array, and use the ttis entry that points to. This assumes that the last set of rules in force were used to generate at least 400 years of entries in ats. Is that correct? But, the code to set goforward based on the ats array decides TRUE if there exists an entry that is equivalent to the last entry but exactly 400 years earlier. That does not guarantee that the last 400 years was meant to be repeated. I'm guessing that zic fills out a whole cycle of the last set of rules in force and then one more ats entry to serve as a cue for tzload, or that the POSIX string could generate more than one complete cycle (i.e. MAX_TIMES was large enough). But simply setting a flag in the header, or noting that the POSIX string existed and could fill out 400 years, would be clearer and avoid hidden meanings. As it is, zic would have to be careful to avoid letting that cue occur by happenstance. If you don't worry about that happening, why worry about 'goback', which never occurs in the actual data? Any newly minted time zone would inherit the past from the region is split off from, so it never will. --John

1 0

code review issue re t outside of ats array's range
by John Dlugosz Jan. 13, 2009

Jan. 13, 2009

In 'localsub', If t is before the first entry in ats, and goback is not set, then it uses the first non-DST entry in ats. But, if t is after the last entry in ats and goforward is not net, then it uses the last entry in ats, regardless of whether it is a DST or standard time entry. Is that intentional? ... thinking ... time passes ... I think it's an error either way - if the ats table ends with a seasonal time change and it isn't flagged as goforward, it should be an error that the table was declared too small. It stays in DST forever and if it's flagged as DST that means it was supposed to be a temporary adjustment to the Zone definition. --John

1 0

Timezone code question
by John Dlugosz Jan. 13, 2009

Jan. 13, 2009

The zic program goes to the trouble of generating a POSIX string for "the future" that is the last thing in the data file. The library code turns that into two more ttis records. Why not just store two more ttis records in the file in the first place? What does 'ttis' stand for? What about 'ats'?

1 0

Leap Second Data
by John Dlugosz Jan. 13, 2009

Jan. 13, 2009

Why is the leap second data associated with each data file? Shouldn't it be the same everywhere? --John

1 0

FW: time zone library
by Olson, Arthur David (NIH/NCI) [E] Jan. 12, 2009

Jan. 12, 2009

I'm forwarding this message from John Dlugosz, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. --ado -----Original Message----- From: John Dlugosz [mailto:JDlugosz@TradeStation.com] Sent: Tuesday, January 06, 2009 7:10 To: tz(a)lecserver.nci.nih.gov Subject: time zone library I downloaded the timezone library, and in adapting it to my needs I've been figuring out how it works. I have a few questions, and also (hopefully) a contribution. First, my contribution. Regarding /* ** Adapted from code provided by Robert Elz, who writes: ** The "best" way to do mktime I think is based on an idea of Bob ** Kridle's (so its said...) from a long time ago. ** It does a binary search of the time_t space. Since time_t's are ** just 32 bits, its a max of 32 iterations (even at 64 bits it ** would still be very reasonable). */ I'm using 64-bit time_t values, and find that it usually takes 62 to 64 iterations. Basically, it is always worst case. I tried using a rough guess for the initial hi and low: lo = ((yourtm.tm_year-70) * 365i64 + yourtm.tm_mon * 28) * SecondsPerDay; hi = ((yourtm.tm_year-70) * 366i64 + (yourtm.tm_mon+1)*31) * SecondsPerDay; when the resulting time_t would be positive, and it completes in 20 to 23 iterations. I punted on the negative case, but a very similar calculation would work. When tm_year < 70, I just used the smallest value I care about for lo, and 0 for hi. That gives me worst case 35 iterations, because I'm only supporting values back to 1752 CE, not the full range of a 64-bit number, which would be 21 times longer than the age of the universe. Now for my first question. TZ_MAX_TIMES is 1200, and that is exactly the length of the arrays for state::ats and state::types. I suppose it is noting every time change, e.g. DST adjustments twice a year for 600 years? There is no need to store anything before the first reported time in the configuration files, as it simply uses the first entry for anything older (no DST in pre-history); it seems to have code for dealing with dates beyond the end of the table. Does it extrapolate the current DST rule in the future? I'd like to cut off the table at a more reasonable date for my application. Where is that table populated? Is it when the data file is loaded, or in zic when it is created? My second question concerns leap seconds. It appears that the leap second data is associated with every zone file. Why isn't it simply the same for everything, and global? --John

4 5