I am in need of some assistance in configuring the time display on
the .rcfile, I have managed to configure the local time (EDT) and date in the lower left corner of the display and the UTC date and time on the lower right -- well almost. The date that is supposed to be UTC remains as the local date. The result is that the date is wrong between 20:00 and 24:00 local each day. I have found the UTC switches for UTC hour (%G) and minutes (%N) but I cannot find what I should use for UTC day of the week, day, month, and year. I have a
Not sure what language but the usual approach is: get a date/time variable as utc time (e.g. seconds since the epoch) and convert that using the general formatting rules. So instead of datestring("format goes here"), pass the utc time variable as an extra parameter: datestring("format", utcvalue).
This is all there is (function writeStrip in sunclock.c)
I suggest you add some code to this section and recompile
############################################## case 'G': sprintf(num, "%02d", gtp.tm_hour); break; case 'H': sprintf(num, "%02d", ltp.tm_hour); break; case 'M': sprintf(num, "%02d", ltp.tm_min); break; case 'N': sprintf(num, "%02d", gtp.tm_min); break; case 'P': num[0]=ampm; num[1]='\0'; break; case 'S': sprintf(num, "%02d", ltp.tm_sec); break; #ifdef NEW_CTIME case 'Z': strcpy(num, ltp.tm_zone); break; #else case 'Z': strcpy(num, tzname[ltp.tm_isdst]); break; #endif case 'a': strcpy(num, Day_name[ltp.tm_wday]); break; case 'd': sprintf(num, "%02d", ltp.tm_mday); break; case 'h': sprintf(num, "%02d", hour); break; case 'j': sprintf(num, "%02d", 1+ltp.tm_yday); break; case 'b': strcpy(num, Month_name[ltp.tm_mon]); break; case 'm': sprintf(num, "%02d", 1+ltp.tm_mon); break; case 't': { int w = ltp.tm_year+1900; if (w % 4==0 && (w % 100!=0 || w % 400 == 0)) w = 366; else w = 365; sprintf(num, "%d", w); break; } case 'y': sprintf(num, "%02d", ltp.tm_year%100); break; case 'Y': sprintf(num, "%d", ltp.tm_year+1900); break; case 'U': { struct tm ftm; time_t ftime; int w; /* * define weeknumber * week #1 = week with the first thursday */ /* set reference date to 1st of january,
12:00:00 */ (void) memset(&ftm, 0, sizeof(struct tm)); ftm.tm_isdst = -1; ftm.tm_mon = 0; ftm.tm_mday = 1; ftm.tm_year = ltp.tm_year; ftm.tm_hour = 12; ftm.tm_min = 0; ftm.tm_sec = 0; ftime = mktime(&ftm); ftm = *localtime(&ftime); /* get first sunday (start of week) */ if (ftm.tm_wday < 5) w = 1 - ftm.tm_wday; else w = 8 - ftm.tm_wday; /* get weeknumber */ sprintf(num, "%02d", ((ltp.tm_yday+1-ltp.tm_wday-w)/7)+1); break; } case '_': c = ' '; default: num[0] = c; num[1] = '\0'; break;
--
Microsoft : the best reason to go to Linux that ever existed.
That certainly looks doable. Copy and paste the appropriate lines, select new letters, and replace "ltp" with "gtp". I will give it a try. Thanks for your help and also to A. Dumas for taking the time to reply.
That was a noble idea. I added the following lines to sunclock.c after ?case 'Y'? at line 2048.
/* * Begin Add for UTC Week
*/ case 'f': strcpy(num, Day_name[gtp.tm_wday]); break; case 'e': sprintf(num, "%02d", gtp.tm_mday); break; case 'k': sprintf(num, "%02d", 1+gtp.tm_yday); break; case 'c': strcpy(num, Month_name[gtp.tm_mon]); break; case 'n': sprintf(num, "%02d", 1+gtp.tm_mon); break; case 'v': { int w = gtp.tm_year+1900; if (w % 4==0 && (w % 100!=0 || w % 400 == 0)) w = 366; else w = 365; sprintf(num, "%d", w); break; } case 'w': sprintf(num, "%02d", gtp.tm_year%100); break; case 'W': sprintf(num, "%d", gtp.tm_year+1900); break;
/* * End Add for UTC Week
*/
I figured that was enough to at least try but that is where the experiment ended. Let me first preface this by stating that although I have been a Slackware user for many years, this is my first foray into Raspian. When I went to compile after the additions, I was expecting to do ?./configure?, ?make?, and ?make install?, but after reading the INSTALL file I knew that was not going to happen. I first tried ?xmkmf ?, but that resulted in ?command not found?.
I next tried. ?make -f Makefile.noimake ? but that immediately resulted in ?fatal error: X11/Xatom.h: No such file or directory?. A search for ?Xatom.h.? showed that it was more than a path problem. It just wasn?t there on the Pi.
A search on my Slackware server however showed that it did have an ?Xatom.h? file so I tried to do a compile on that using ?make -f Makefile.noimake?. It apparently then found the ?Xatom.h? file but it also produced tons of new warnings and errors until it finally bombed out. I tried it with both the unmodified and modified versions of sunclock.c, so it is not just my tinkering that was the problem, although I have to admit there were a few more errors in the modified version.
Based on my level of expertise, as in a lack of, I think I am done on this effort.
i thought you already HAD a working compile setup?
I wish I had time to sort this out for you, but I do not.
Hopefully someone else with an actual Pi can.
--
"I am inclined to tell the truth and dislike people who lie consistently.
This makes me unfit for the company of people of a Left persuasion, and
all women"
What a kind way to let me know my reply sucked ;) So, the language is C. Can you not include time.h and use gmtime() and strftime() in the way I suggested?
If you read my post, the source is clear and the changes needed are trivial. The problem is he cant get a working compile from source set up.
I am not clear as to whetrher he downloaded source from e.g. github or downloaded the package source. If the latter it OUGHT to compile and pull in the right dependencies.
But its abeen a long time since I compiled a package from distro source. Cant even remember how its done.
--
It?s easier to fool people than to convince them that they have been fooled.
Mark Twain
You need to install the build-dependencies as well. dpkg-buildpackage[1] will tell you what they are.
[1]
formatting link
You don?t need to be root to build Debian packages from source. The only step that needs a root-like environment is the assembly of build products into a .deb file, and fakeroot is sufficient for that (and is what dpkg-buildpackage uses).
I hoped you would step in and provide chapter and verse.
Cheers!
--
"Corbyn talks about equality, justice, opportunity, health care, peace,
community, compassion, investment, security, housing...."
"What kind of person is not interested in those things?"
"Jeremy Corbyn?"
As a first time user of Raspian and the Pi, this has been quite a lengthy learning experience. After much reading I found and installed the ?Synaptic Package Manager? That allowed me to find and install all the packages needed to use ?xmkmf?. Once I had ?xmkmf? installed, I continued to use SPM to find and install the needed packages to provide files such as Xatom.h that ?xmkmf? said were missing during the compile. With each stumbling block overcome, I was hopeful that I might eventually reach a point of a complete compile - but apparently not.
The latest compile (without any modifications to the source code) ended with many errors that all stated the same thing about ?*fd is a pointer..? The first error message is shown below.
______
In file included from readvmf.c:31:0: readvmf.c: In function ?getdata?: readvmf.c:353:7: error: ?*fd? is a pointer; did you mean to use ?->?? i = gzgetc(fd); ^ -> _______
As someone who only has experience in writing bash scripts, I am not sure I will live long enough to do all the reading needed to fix those errors without creating a bunch of new errors.
P.S. After doing the above I came back here and noted your wiki link but I think that page only suggested what I was doing here using a different set of steps - unless I missed something. That is very possible.
Perhaps you can tell for sure based on my responses further down.
I have tried several different source code packages without success. The one I am currently using is from ?Master.zip? that I downloaded using this link.
formatting link
It unzips to several files and directories and one of directories, ?sunclock-3.57?, seems to have the source code. Most of the files are dated Aug 14 2016 so I would think that is the latest and greatest version.
As suggested I ran ?sudo dpkg-buildpackage?. My first attempt failed because, as you suspected, it was missing the following dependencies
debhelper libjpeg62-dev libpng12-dev dpatch
I installed these four and tried again. This time I received bunch of warnings. The one that was repeated most often is the one below but there were others.
_____________
?warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE?
_____________
I also had a group of eight identical errors one of which is shown below. These errors were same kind as the ones I received previously using ?make?
____________
readvmf.c:353:7: error: ?*fd? is a pointer; did you mean to use ?->?? i = gzgetc(fd); ^ -> ___________
This time the end message was as follows.
___________
: recipe for target 'readvmf.o' failed make[1]: *** [readvmf.o] Error 1 make[1]: Leaving directory '/home/pi/Downloads/Sunclock-master/sunclock-3.57' debian/rules:25: recipe for target 'build-stamp' failed make: *** [build-stamp] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2
I havent time to check that one through, but that is typical of a compile where the wrong or no header file is in play.
The point I am making and I wish I could do more, is that source packages are what the distro package is built FROM so they MUST work.
It may be that you have installed so much stuff by hand that its being accessed instead of the source package stuff. BTDTGTTS.
--
?I know that most men, including those at ease with problems of the
greatest complexity, can seldom accept even the simplest and most
obvious truth if it be such as would oblige them to admit the falsity of
conclusions which they have delighted in explaining to colleagues, which
they have proudly taught to others, and which they have woven, thread by
thread, into the fabric of their lives.?
? Leo Tolstoy
That?s a bug in sunclock. The Debian package in stretch disabled zlib support to work around this issue in 2012:
| sunclock (3.57-1) unstable; urgency=low | | [...] | * Disable ZLIB, because this causes trouble with zlib 1.2.6. | | -- Roland Rosenfeld Mon, 05 Mar 2012 14:52:35 +0100 Your other post implies you?re not using that but have actually got source code from some other, hopelessly out-of-date, source.
Get the source code for the distribution you?re using, from that distribution, using ?apt-get source sunclock?, and try again.
I did read that in past posts, but when things are giving error messages you try everything might help. I did try it without the "sudo" first.
Glad to know there might be a light at then end of the tunnel that is not a train coming from the opposite direction.
It took me a while to get rid of the message about needing a URI and learning enough to alter /etc/apt/sources.list.d/raspi.list but I think "apt-get source" is now working the way it should and the message below is what I receive.
_________
pi@raspberrypi:~/temp $ apt-get source sunclock Reading package lists... Done E: Unable to find a source package for sunclock
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.