Information: Forum is in read-only mode
For details and other support options see

Where are the timezones kept?

General discussions here

Moderator: alorbach

Google Ads

Where are the timezones kept?

Postby seasoned_geek » Tue Feb 13, 2018 4:47 pm

I couldn't find an appropriate and active place to ask this question. It looked like the developers corner hadn't had a message since 2017.

I pulled down rsyslog-master as part of my other question about forwarding message format and wrong time. I have been tracking back through the time routines and got as far as

Code: Select all
cnfDoObj(struct cnfobj *const o)
   int bDestructObj = 1;
   int bChkUnuse = 1;
   assert(o != NULL);

   dbgprintf("cnf:global:obj: ");
   switch(o->objType) {

After that I lost the trail. I've been in software development for over 30 years. I was developing business applications which clustered across continents long before anyone had ever heard the word Internet. I've even written quite a few geek books, some of which have won awards, one of which is on the Dr. Dobb's list. I'm not saying all of that to brag. Nobody here knows me so there is no valid frame of reference to evaluate the statement I'm about to make.

This code is impossible to follow.

Even using Grep and the Dolphin graphical search I couldn't find a call which appeared to actually get to glblProcessTimezone(). More importantly, I couldn't find a single file containing CST, EST, and the handful of other timezone values listed on the documentation page, which for some reason is throwing up "internal error" messages now that I try to load it. I looked in all of the .conf files under /etc/rsyslog.d and I even looked in /etc/rsyslog.conf. I cannot find where rsyslog loads any timezone information.

Does the default YABU (Yet Another uBUntu) rsyslog come without any timezone configuration?
Does the rsyslog-master contain no timezone configuration?
Where should timezone configuration be stored? I would assume some .conf file or a header file, but assumptions lead one down long dark rabbit holes.

I was a bit shocked when my journey lead me through the top of datetime.c and I encountered this

Code: Select all
/* the following table saves us from computing an additional date to get
 * the ordinal day of the year - at least from 1967-2099
 * Note: non-2038+ compliant systems (Solaris) will generate compiler
 * warnings on the post 2038-rollover years.
static const int yearInSec_startYear = 1967;
/* for x in $(seq 1967 2099) ; do
 *   printf %s', ' $(date --date="Dec 31 ${x} UTC 23:59:59" +%s)
 * done |fold -w 70 -s */
static const time_t yearInSecs[] = {
   -63158401, -31536001, -1, 31535999, 63071999, 94694399, 126230399,
   157766399, 189302399, 220924799, 252460799, 283996799, 315532799,
   347155199, 378691199, 410227199, 441763199, 473385599, 504921599,

Did someone really code a Y2K99 bug?
Posts: 4
Joined: Sat Feb 10, 2018 11:00 pm

Urgent Question?

  • Pulling out your Hair?
  • Wasting Time and Money?
  • Deadline Approaching?

Google Ads

Return to General

Who is online

Users browsing this forum: No registered users and 1 guest