- tz - lists.iana.org

[PROPOSED PATCH] * zdump.c (adjusted_yday): Define only if TM_GMTOFF is not defined.
by Paul Eggert Oct. 5, 2014

Oct. 5, 2014

--- zdump.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/zdump.c b/zdump.c index 37a0926..13bbb0e 100644 --- a/zdump.c +++ b/zdump.c @@ -851,8 +851,9 @@ delta(struct tm * newp, struct tm *oldp) return result; } +#ifndef TM_GMTOFF /* Return A->tm_yday, adjusted to compare it fairly to B->tm_yday. - Assume A and B differ by at most one year. */ + Assume A and B differ by at most one year. */ static int adjusted_yday(struct tm const *a, struct tm const *b) { @@ -861,6 +862,7 @@ adjusted_yday(struct tm const *a, struct tm const *b) yday += 365 + isleap_sum(b->tm_year, TM_YEAR_BASE); return yday; } +#endif /* If A is the broken-down local time and B the broken-down UTC for the same instant, return A's UTC offset in seconds, where positive -- 1.9.1

1 0

coding style for tzcode?
by christos＠zoulas.com Oct. 4, 2014

Oct. 4, 2014

Hello, The code used to be 8-tab BSD formatted, and now it seems that 2 space indentantion is being used, or 4 space, or whatever random spacing (sometimes contination lines follow the opening parenthesis of the function above, other times they don't) in both new code and diffs from the old code. If people don't like the current coding style, let's decide on a style, reformat all the code to the new style and keep it consistent. What we have now is making the code unreadable. Thank you! christos

2 4

Timezone for Moscow is -10800 after installing tzdata-2014g
by Alexander Koblov Oct. 4, 2014

Oct. 4, 2014

Hi All! My timezone is Europe/Moscow. After installing tzdata-2014g, tzset sets value for timezone not -14400 as before, but -10800, although time shift will be only in October 26th. Is this the expected behavior, or maybe I don't understand something? Please see below program I use for the test and output from console. Notice, how depends on what version of tzdata is installed value of timezone is different, although current time is the same. My question is: Why tzdata-2014g returns timezone for the Europe/Moscow -10800 (3 hours)? As far as I understand timezone for Moscow should be changed on the night of 25/26 October. Thank you, Alexander. ========== #include <iostream> #include <ctime> #include <cstdlib> using namespace std; int main() { tzset(); //set all 4 DST globals using TZ cout<< "the difference between UTC and the local standard time is: "<<timezone<<endl; cout<<boolalpha; //switch to verbal representation of bools cout<<"DST in effect: "<<(bool) daylight<<endl; cout<<"local standard time code: "<<tzname[0]<<endl; cout<<"local standard time code: "<<tzname[1]<<endl; } ========== ============== // With tzdata-2014g-installed [root@Linux jgm]# ./jtz the difference between UTC and the local standard time is: -10800 DST in effect: true local standard time code: MSK local standard time code: MSD [root@Linux jgm]# date Птн Окт 3 14:43:37 MSK 2014 //Let's downgrade to tzdata-2014b [root@Linux jgm]# yum downgrade tzdata-2014b-1.el6.noarch // skip lines Removed: tzdata.noarch 0:2014g-1.el6 Installed: tzdata.noarch 0:2014b-1.el6 Complete! [root@Linux jgm]# ./jtz the difference between UTC and the local standard time is: -14400 DST in effect: false local standard time code: MSK local standard time code: MSD [root@Linux jgm]# date Птн Окт 3 14:44:05 MSK 2014 //Let's return back to tzdata-2014g [root@Linux jgm]# yum update tzdata //skip lines Updated: tzdata.noarch 0:2014g-1.el6 Complete! [root@Linux jgm]# ./jtz the difference between UTC and the local standard time is: -10800 DST in effect: true local standard time code: MSK local standard time code: MSD [root@Linux jgm]# date Птн Окт 3 14:44:36 MSK 2014 [root@Linux jgm]# ==============

5 5

Handling of uninitialized tm_gmtoff and tm_zone
by random832＠fastmail.us Oct. 2, 2014

Oct. 2, 2014

It is possible that mktime, strftime, etc?, may be called with a struct tm that has not had non-standard members initialized. How does tzcode deal with these cases? (It _looks_ like strftime handles it badly; I can't figure out what, if anything, the mktime implementation does with these members).

2 1

Issue with Jordan timezone
by obulesh kumar Oct. 1, 2014

Oct. 1, 2014

Hi all, I am getting wrong time zone for Jordan in my android device. I am calculating time zone from NITZ information provided by network in Amman country. I am using offset and DST value from NITZ to calculate timezone. Below are the values provided by network on date:15/Jul/2014 OFFSET:10800000 DST:false I am getting from proper timezone for Jordan country in 2013g database version as Asia/Amman. But i am not getting any timezone for Amman country in 2013i database on wards. below is timezone data differences from 2013g to 2013i please find snapshot. [image: Inline image 1] Please help us in resolving this issue. Thanks and Regards, Obulesh

2 4

Aix question
by Donald MacQueen Oct. 1, 2014

Oct. 1, 2014

Hi all, Sorry for the off topic, but does anyone know the procedure for updating tz info on Aix? Google is not my friend today. Thanks in advance. Great work, Paul. -- Donald [|] Joel Cairo: "You always have a very smooth explanation." Sam Spade: "What do you want me to do? Learn to stutter?" - The Maltese Falconn

3 2

Time, Clock, and Calendar Programming In C, by Eric S. Raymond
by random832＠fastmail.us Sept. 30, 2014

Sept. 30, 2014

Eric S. Raymond has written an article about the history of the time.h functions at http://www.catb.org/esr/time-programming/ >From his blog post announcing it (http://esr.ibiblio.org/?p=6311) > The C/UNIX library support for time and calendar programming is a nasty mess of historical contingency. I have grown tired of having to re-learn its quirks every time I’ve had to deal with it, so I’m doing something about that. > > Announcing Time, Clock, and Calendar Programming In C, a document which attempts to chart the historical clutter (so you can ignore it once you know why it’s there) and explain the mysteries. > > What I’ve released is an 0.9 beta version. My hope is that it will rapidly attract some thoroughgoing reviews so I can release a 1.0 in a week or so. More than that, I would welcome a subject matter expert as a collaborator. When I saw it I thought it might be generally interesting to people who subscribe to this list.

1 0

Mehdi Ashrafi
by Mehdi Ashrafi Sept. 29, 2014

Sept. 29, 2014

+989376266654

1 0

(FYI) egypt
by Sebastien WILLEMIJNS Sept. 27, 2014

Sept. 27, 2014

http://journalmetro.com/monde/564625/legypte-change-encore-dheure/ i think you know that....

1 0

[tz-announce] 2014h release of tz code and data available
by Paul Eggert Sept. 26, 2014

Sept. 26, 2014

The 2014h release of the tz code and data is available. It reflects the following changes, which were either circulated on the tz mailing list or are relatively minor technical or administrative changes: Changes affecting past time stamps America/Jamaica's 1974 spring-forward transition was Jan. 6, not Apr. 28. Shanks says Asia/Novokuznetsk switched from LMT (not "NMT") on 1924-05-01, not 1920-01-06. The old entry was based on a misinterpretation of Shanks. Some more zones have been turned into links, when they differed from existing zones only for older time stamps. As usual, these changes affect UTC offsets in pre-1970 time stamps only. Their old contents have been moved to the 'backzone' file. The affected zones are: Africa/Blantyre, Africa/Bujumbura, Africa/Gaborone, Africa/Harare, Africa/Kigali, Africa/Lubumbashi, Africa/Lusaka, Africa/Maseru, and Africa/Mbabane. Changes affecting code zdump -V and -v now output gmtoff= values on all platforms, not merely on platforms defining TM_GMTOFF. The tz library's localtime and mktime functions now set tzname to a value appropriate for the requested time stamp, and zdump now uses this on platforms not defining TM_ZONE, fixing a 2014g regression. (Thanks to Tim Parenti for reporting the problem.) The tz library no longer sets tzname if localtime or mktime fails. zdump -c no longer mishandles transitions near year boundaries. (Thanks to Tim Parenti for reporting the problem.) An access to uninitalized data has been fixed. (Thanks to Jörg Richter for reporting the problem.) When THREAD_SAFE is defined, the code ports to the C11 memory model. A memory leak has been fixed if ALL_STATE and THREAD_SAFE are defined and two threads race to initialize data used by gmtime-like functions. (Thanks to Andy Heninger for reporting the problems.) Changes affecting build procedure 'make check' now checks better for properly-sorted data. Changes affecting documentation and commentary zdump's gmtoff=N output is now documented, and its isdst=D output is now documented to possibly output D values other than 0 or 1. zdump -c's treatment of years is now documented to use the Gregorian calendar and Universal Time without leap seconds, and its behavior at cutoff boundaries is now documented better. (Thanks to Arthur David Olson and Tim Parenti for reporting the problems.) Programs are now documented to use the proleptic Gregorian calendar. (Thanks to Alan Barrett for the suggestion.) Fractional-second GMT offsets have been documented for civil time in 19th-century Chennai, Jakarta, and New York. Here are links to the release files: ftp://ftp.iana.org/tz/releases/tzcode2014h.tar.gz ftp://ftp.iana.org/tz/releases/tzdata2014h.tar.gz The files are also available via HTTP as follows: http://www.iana.org/time-zones/repository/releases/tzcode2014h.tar.gz http://www.iana.org/time-zones/repository/releases/tzdata2014h.tar.gz Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. As usual, links to the latest release files are here: http://www.iana.org/time-zones/repository/tzcode-latest.tar.gz http://www.iana.org/time-zones/repository/tzdata-latest.tar.gz ftp://ftp.iana.org/tz/tzcode-latest.tar.gz ftp://ftp.iana.org/tz/tzdata-latest.tar.gz This release corresponds to commit 651d4deba49e90dd42141bf00dd5e94024100038 dated Thu Sep 25 18:59:03 2014 -0700 and tagged '2014h' in the experimental github repository at <https://github.com/eggert/tz>. Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJUJMkaAAoJEO2X6Q5iqn40/xgP/05GMYGaGlB0SdREMb3Tcl37 ofHu8wIlw/zYPqRQsNJX02G0JMm9Ymsxk58K12DrzQvDragun1WEZFYB3qNJjE7c tGd//0NhVUxoGjxQLjrZ6JDr/AlM56iondkbvVzU+2t7mNrNjABg73Ub750fuSzM qt3tpr/+Ba+fOLcKb9uZQqlt6Bc5qAMGXcsBBT0KVeybLjDobaD66yb6kfZ81uNj g3u60H1JKhEe5NduovMLm5NLRtHa4VJCxJki5pwuYgNtuuG9XYpz2vzQ2DuChO8K hjPzR6MpF/KsICAeAsgf+Z6FqDG8LBy39DeyZCwjP9pDPu3VekuW0dpe3Jad/eTC lQB5dubGPkqS6dW1CepoU/Oojdh9CUmlLYIZDCadpE7RfOFqTLLMnEzhVIv2Iluw 5ssTJ0YTomA8XfdVFHoxdZ/woEYg32KF6ssYOOt8+M4xNLNc0zpjLnnwbfpZN1bN SOGnSWkogssPh60Otd60Zy1mx9KnOQAvzQHHMlqRJTCxnVqvLwP2LaUZaYP2nkuo 7WLqGFIjfCc2iIckogkkPotTVNsTuc+FSV6Ck/GMTEHRZrAX34u/iNr2jik7n85s OjEKWz3WKO8Zo7GOk/w7Ekmnt/UzDLEL4RDB2yxWETI8zTxkzfLmEGT/hFVt2JiG yeg7CpXKQtimBKMnMRXl =DxQr -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJUJMkaAAoJEO2X6Q5iqn40AcwQAICQe7AszG667Q3EX+jrrvMi np5LQs6UlCJzU+xwpQ0zo8OANPaJRVe11A//j4eWAkZjXGLrpj8GwDNV+AMnPTtB b1UGos9oOitFBsJfXrwRsOUUuMFHUmnIWvIkS6FY3uCG31wXZVUDuRnksUifnB24 Agmz9KI5Be6JHr3d4erzu7rp7gU4FslJ1f4Jvmiy+PnPiMkZJAsf3Lu+O77h/0qR sZNsigf8lXoIakHAQtNiwizk6a1fTAc6VElgk7hwQ9rm1FxiEWWidWv1bF52qbAw kTrdFZEUY5ONe5O8deAf9r3GVKh/3HmMa8Bzf23a8eSDjLrJbhFTb1uZ5P0vRoHu SabrtvhLg8hrUD3RJtEM1rwROaCrdUTfz002DrOX7htA6m9P3af7OmzkWDJ0hlGe EOeAa1YkjcPwGmbYxCWQbexM2KHr4MaIJ1v75lduq1+osEr1dOvzU8/KJzmay59s XWrXXa7ihPyIW+0MCWqTZg8AqTTed9SwMvWRw2gZTM4L23PerfzmM0PzffdY4oCX 9mbCGTKjp+gcMChRJ+Rtf2xlgsHy5uk2tFVCMngL0FW4rm5EIW8R2GhRBrSAkKYb m8KPvc1+ErjK7nkDpFQ1LKk8/H0v08Yk/aYfRmC4IhmJRzB33Ei0ZuWTqU3ilzJ5 743/HDLWaGvpbG639WBU =a4Y0 -----END PGP SIGNATURE----- _______________________________________________ tz-announce mailing list tz-announce(a)iana.org https://mm.icann.org/mailman/listinfo/tz-announce

1 0