Jump to content

Recommended Posts

  • 68kMLA Supporter
10 hours ago, karrots said:

I've used Vremya to set time on my system 7.5.5 system. It uses SNTP so UTC which then I have to change the timezone. Which is also unfortunately stored in PRAM.

 

Ah, I've been meaning to try Vremya out, glad to hear it works :-) SNTP is a sensible protocol to use for machines that have IP, certainly.  The nice thing about timelord is that because it runs over AppleTalk, you don't need any supporting network configuration, really; you just drop a 6kb rdev into the system folder and off it goes.  Personally I'm a big fan of the 68000 compacts, and not having the overhead or faff of an IP stack on those is really nice.

 

Also it's cool to make stuff work that didn't work before :-).

Link to post
Share on other sites
  • 68kMLA Supporter
2 minutes ago, karrots said:

Not trying to detract. Just noting the time set and timezone behavior. This was all done from my Classic II with no battery.

 

No, I know you weren't, don't worry :-).

 

Do you know whether the timezone offset is applied before or after the actual system clock, though?

Link to post
Share on other sites
  • 68kMLA Supporter

When I boot up the time is wrong.

I set the time using Vremya it's in UTC.

I open the Date/Time control panel and change the timezone. The menu bar clock then shows the proper time.

 

Does that help?

Link to post
Share on other sites
  • 68kMLA Supporter
14 hours ago, cheesestraws said:

mtime = tv.tv_sec + EPOCH + tm.tm_gmtoff;

 This seems to be not correct.  if I run make...there is  an error:

 

gcc -DHAVE_CONFIG_H -I. -I../..     -I../../include -D_U_="__attribute__((unused))" -g -O2 -I../../sys -MT timelord.o -MD -MP -MF .deps/timelord.Tpo -c -o timelord.o timelord.c
timelord.c: In function ‘main’:
timelord.c:234:43: error: ‘tm’ is a pointer; did you mean to use ‘->’?
             mtime = tv.tv_sec + EPOCH + tm.tm_gmtoff;
                                           ^
                                           ->
make[3]: *** [Makefile:490: timelord.o] Error 1
make[3]: Leaving directory '/AppleShare/TimeLord/netatalk-2.2.6/contrib/timelord'
make[2]: *** [Makefile:451: all-recursive] Error 1
make[2]: Leaving directory '/AppleShare/TimeLord/netatalk-2.2.6/contrib'
make[1]: *** [Makefile:499: all-recursive] Error 1
make[1]: Leaving directory '/AppleShare/TimeLord/netatalk-2.2.6'
make: *** [Makefile:429: all] Error 2

 

Link to post
Share on other sites
  • 68kMLA Supporter
49 minutes ago, mactjaap said:

 This seems to be not correct.  if I run make...there is  an error:

 

Ooops!  My fault.  The error is totally correct, try:

 

mtime = tv.tv_sec + EPOCH + tm->tm_gmtoff;

 

instead.

 

1 hour ago, karrots said:

Does that help?

 

It's highly suggestive! Thankyou :-)

Link to post
Share on other sites
  • 68kMLA Supporter
21 minutes ago, cheesestraws said:

Does that help?

YES! It now compiles without any error. And it differs from the old file.

 

diff /usr/sbin/timelord /AppleShare/TimeLord/netatalk-2.2.6/contrib/timelord/timelord
Binary files /usr/sbin/timelord and /AppleShare/TimeLord/netatalk-2.2.6/contrib/timelord/timelord differ

 

Test it ...now.

Link to post
Share on other sites
  • 68kMLA Supporter
Posted (edited)

No...doesn't work. Still the UTC I'm afraid. But this is only from server side. Could be different on a real Macintosh? I test this evening.

 

Jun  8 16:57:32 localhost timelord[1208]: gettime from MacIPgw in chooser was 3706009051


3706009051
Converting timestamp 3706009051:
GMT: Tuesday 8 June 2021 14:57:31

 

My system is set to localtime two hours later.

 

$date
Tue  8 Jun 16:57:08 CEST 2021

 

 

Edited by mactjaap
Link to post
Share on other sites
  • 68kMLA Supporter
10 minutes ago, mactjaap said:

No...doesn't work. Still the UTC I'm afraid. But this is only from server side. Could be different on a real Macintosh? I test this evening.

 

ah, damn.  Oh well, the theory was sound.  I'll poke it when I get a chance...

Link to post
Share on other sites
  • 68kMLA Supporter
Posted (edited)

I'm glad I tried it also on a real Macintosh. YES! 7:09:56 PM ( is the same as 19:09:56 as show on a clock on my iPhone.)

It is updating alright on my Macintosh ED.

 

succes.thumb.JPG.dcb08e31bb1f5ff707793f22eb940f91.JPG

 

 

The logging is providing false information about what is done.

First time I get this in /var/log/daemon.log

 

Jun  8 19:05:10 localhost timelord[1208]: gettime from macipgw in chooser was 1841229651

 

Second time this:

 

Jun  8 19:08:37 localhost timelord[1208]: gettime from macipgw in chooser was 3706024116



 

 

You have saved timelord from history. I'm very glad there is now a working version. 

 

I will include this binary on the next update of my MacIPRpi. ( with credits to you and a link to this post).

Edited by mactjaap
Link to post
Share on other sites
  • 68kMLA Supporter
5 hours ago, mactjaap said:

The logging is providing false information about what is done.

 

Looking at the code, when the Mac requests the time, it looks like it sends the time server its own current time (why?  who knows).  And what's being printed there is the time the mac is sending to the server, not the time the server is sending to the Mac.  So the first time it will print total rubbish, because the mac's clock could contain anything.  I've no idea why this is a thing; I assume there was a use for it in the original tools.

 

I'm still not totally sure how the version with localtime will behave when there's a time zone set on the Mac itself; might be worth bouncing up and down on that a bit and checking it works properly.

 

5 hours ago, mactjaap said:

You have saved timelord from history. I'm very glad there is now a working version. 

 

I will include this binary on the next update of my MacIPRpi. ( with credits to you and a link to this post).

 

Woo, I'm glad it's working for you :-).  Another bit of functioning old software is a good thing :D.

Link to post
Share on other sites
On 6/4/2021 at 10:05 AM, cheesestraws said:

 

Yeahhh.  How does your build system work?  Do you build netatalk 2 from sources and/or patch locally?  If you want to do this as part of an automated build, it might be better if I send you a copy of timelord.c suitable for dropping directly into the netatalk2 source tree in replacement for the old one, rather than the one I posted above which is tweaked to build standalone

The best would be a patch (diff) against the netatalk-2.2.6 source.

Link to post
Share on other sites
  • 68kMLA Supporter
16 hours ago, NJRoadfan said:

The best would be a patch (diff) against the netatalk-2.2.6 source.

 

Here you go.  The gmtpatch is my original one; I think this will work if you are serving to Macs that have their time zone properly set in CMOS (?!).

 

The localtime patch is the one that hands out local time, per @mactjaap's posts above.  This will work properly for Macs in non-UTC timezones that think they're in UTC, or don't think about timezones at all.

 

Perhaps this should be a command line option; what think ye all?

gmtpatch.patch localtimepatch.patch

Link to post
Share on other sites
  • 68kMLA Supporter

For now I will deploy both version on the MacIPRpi.

 

I just compiled both versions and set the correct one in /etc/init.d/netatalk. If a user doesn't want local time it can be changed there.

 

 

TIMELORD_RUN=yes
TIMELORD_LOCAL=yes

 

 

# timelord revisited

    if [ "x$TIMELORD_RUN" = "xyes" -a "x$TIMELORD_LOCAL" = "xyes" ]; then
                        echo "Starting Timelord in localtime."
                        /usr/sbin/timelord.localtime
                else
                        echo -n "Starting Timelord in UTC. "
                        /usr/sbin/timelord.gmt
                        echo "."
                fi


#        if [ x"$TIMELORD_RUN" = x"yes" ]; then
#            /usr/sbin/timelord
#            echo -n " timelord"
#        fi

 

Link to post
Share on other sites
  • 68kMLA Supporter
Posted (edited)
1 hour ago, mactjaap said:

I just compiled both versions and set the correct one in /etc/init.d/netatalk. If a user doesn't want local time it can be changed there.

 

That's a nice solution.

 

1 hour ago, mactjaap said:

else

 

It won't let me quote your code, but you probably want an elif [ "x$TIMELORD_RUN" = "xyes" ] instead of the else here.  Otherwise if TIMELORD_RUN is not yes, the whole first condition will fail, the else block will run, and timelord.gmt will be started anyway.

Edited by cheesestraws
Link to post
Share on other sites
  • 68kMLA Supporter

Ah. Yes. Thanks. As I have it now you cannot escape from the Timelord :-)

I will fix it in my new release.

 

For people with a MacIPRpi and who cannot wait.... I attach both executables

 

https://cdn.macip.net/timelord.utc

https://cdn.macip.net/timelord.localtime

 

For now to keep it simple ... use the one that you want and rename it to timelord in  the directory /usr/sbin/

Link to post
Share on other sites
  • 68kMLA Supporter

Changed it in:

 

# timelord revisited

    if [ "x$TIMELORD_RUN" = "xyes" -a "x$TIMELORD_LOCAL" = "xyes" ]; then
                        echo ". Starting Timelord in localtime."
                        /usr/sbin/timelord.localtime
    elif [ "x$TIMELORD_RUN" = "xyes" -a "x$TIMELORD_LOCAL" = "xno" ]; then
                        echo -n ". Starting Timelord in UTC. "
                        /usr/sbin/timelord.utc
    else
                        echo -n ". Timelord is disabled in Netatalk settings (/etc/init.d/netatalk)"
         fi

 

Link to post
Share on other sites
  • 68kMLA Supporter

A week later.... New idea. Why not run two instances of TimeLord? One in LocalTime and one in UTC. 

A MacIPRpi user can choose which one to use, without manual configuration. I use the option -n to give Timelord a nice name on the network.

 

macipgw@macippi:~ $ nbplkup
                            UTC:TimeLord                           65280.243:130
                      LocalTime:TimeLord                           65280.243:131

 

I think I will implement this in the next release of the MacIPRpi.

 

82419284_WhatsAppImage2021-06-19at15_06_06(3).thumb.jpeg.3921c1958a470d3fba9d675b6b08d3ae.jpeg

 

546398987_WhatsAppImage2021-06-19at15_06_06(4).thumb.jpeg.14c8a39a21c00bffdab3122b65fc5e08.jpeg

 

 

 

 

 

 

Edited by mactjaap
Showing UTC and LocalTime pictures
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...