Formatting for UTC Date Using Sunclock 3.56 ???

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

Reply to
NotReal
Loading thread data ...

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).

Reply to
A. Dumas

On 23/09/18 21:17, NotReal wrote:

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.
Reply to
The Natural Philosopher

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.

Reply to
NotReal

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.

Thanks for trying.

Reply to
NotReal

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"
Reply to
The Natural Philosopher

Nope. I used "apt-get install sunclock"

Not a problem. I did not expect you do more. I thank you for what you did do.

Reply to
NotReal

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?

Reply to
A. Dumas

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
Reply to
The Natural Philosopher

formatting link

Download the source pakage and proceed as indicated. It should 'just build'

You need to be root probly to build stuff

Then make the changes and try again.

--
Microsoft : the best reason to go to Linux that ever existed.
Reply to
The Natural Philosopher

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).

--
https://www.greenend.org.uk/rjk/
Reply to
Richard Kettlewell

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?"
Reply to
The Natural Philosopher

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); ^ -> _______

It then exited with

_______

: recipe for target 'readvmf.o' failed make: *** [readvmf.o] Error 1

______

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.

Reply to
NotReal

I susopecvt you are using entrirely te wrong build tools

You didnt download the source package did you?

You are almost certainly missing some library or header files

No, that is a sumpole apt based system no xkmf involved

--
No Apple devices were knowingly used in the preparation of this post.
Reply to
The Natural Philosopher

Oh I see, the work has already been done with ltp vs. gtp, yeah.

Reply to
A. Dumas

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.

I used this link to see what I needed.

formatting link

This is what I have at the moment

libc6:armhf libc6-armhf-cross libc6-dbg:armhf libc6-dev:armhf libc6-dev-armhf-cross libjpeg62-turbo:armhf libjpeg62-turbo-dev:armhf libpng16-16:armhf libx11-6:armhf libxpm4:armhf

I could not find sumpole but I did see references to simple apt. I am hoping that was just a typo. Either way it looks like I need to do more reading.

And people have told me Slackware is not the easiest distribution. It seems much easier to me than this.

Reply to
NotReal

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

__________

The fun never stops.

Reply to
NotReal

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
Reply to
The Natural Philosopher

You do not need root here. See above.

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.

--
https://www.greenend.org.uk/rjk/
Reply to
Richard Kettlewell

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

_________

I then did a

/var/lib/apt/lists $ grep sunclock *

and found the line.

raspbian.raspberrypi.org_raspbian_dists_stretch_main_binary-armhf_Packages:Sourc e: sunclock

but it didn't find "sunclock" in any of the

archive.raspberrypi.org_debian_dists_stretch_main_source_Sources

or

archive.raspberrypi.org_debian_dists_stretch_ui_source_Sources

lists.

The one thing that bothers me though is that there are 57020 packages listed in

raspbian.raspberrypi.org_raspbian_dists_stretch_main_binary-armhf_Packages

but only 305 packages listed in

archive.raspberrypi.org_debian_dists_stretch_main_source_Sources

so I am probably not doing something right. I would not think there would be so few sources available for that many binaries. ???

Reply to
NotReal

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.