Possible Time Stamp Shifting Between System Time And App

Please reproduce your error on a second machine before posting, and check the error by running without saved changes or extra modules (See FAQ No. 13, "How to report a bug"). For unstable Porteus versions (alpha, beta, rc) please use the relevant thread in our "Development" section.
jimwg
Shogun
Shogun
Posts: 322
Joined: 09 Oct 2013, 18:15
Distribution: porteus
Location: NYC

Possible Time Stamp Shifting Between System Time And App

Post#1 by jimwg » 25 Oct 2013, 08:57

Greetings!

I'm raising this to a possible bug report after the third instance of someone in our home school discovering this anomaly after installing Porteus 2.1 32bit. This is a copy of the topic Stellarium displays 4 Hours Behind Local Time In Porteus.

I first noticed it in Stellarium 11.0 under Porteus 2.1 (XFCE 4.10 install) 32bit in that Stellarium always renders displays four hours ahead local time for me, even though I rechecked Porteus time settings and have UTC off. It doesn't occur under Puppy and Mint. My recent and current Seamonkey Mail time stamps new mail as being four hours ahead of local time as well.

Is it possible that Porteus alters time between an app and the system time? If not, what can explain this?

I'd rather jump the gun on a mistake on our part than shrug off a possible bug on a fantastic OS.

Jim in NYC

User avatar
fanthom
Moderator Team
Moderator Team
Posts: 5666
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland
Contact:

Re: Possible Time Stamp Shifting Between System Time And App

Post#2 by fanthom » 25 Oct 2013, 14:08

couldn't recreate your problem - Stellarium always display the system time correctly.
maybe you could switch from localtime to UTC? please boot with 'timezone=America/New_York' and check if everything is ok.
if not then please post an output of the 'date' command and screenshot from of the Stellarium application (delayed capture should do the trick).
Please add [Solved] to your thread title if the solution was found.

jimwg
Shogun
Shogun
Posts: 322
Joined: 09 Oct 2013, 18:15
Distribution: porteus
Location: NYC

Re: Possible Time Stamp Shifting Between System Time And App

Post#3 by jimwg » 25 Oct 2013, 16:58

fanthom wrote:couldn't recreate your problem - Stellarium always display the system time correctly.
maybe you could switch from localtime to UTC? please boot with 'timezone=America/New_York' and check if everything is ok.
if not then please post an output of the 'date' command and screenshot from of the Stellarium application (delayed capture should do the trick).
My local time in the system panel clock is correct. That's not the problem. It's the apps where time has gone wonky. My Seamonkey mail menu displays latest mail up is only minutes fresh (now being 12:48 pm) as being date stamped instead four from now at 4:48 pm. It is 12:48 pm now here in NYC yet in Stellarium the sun is just climbing above the horizon in the display as it would look at 8:48 am yet Stellarium's menu clock correctly reads real-time at 12:48. Via Proteus time manager panel I click to UTC with New York which switches time ahead four hours in Stellaruim which now displays the sun is at proper real-time noon time now at 12:48 pm almost overhead but at 4:48 pm Stellarium menu time and system real-time. This is a live check of the time shift and it's not just Stellarum. Time-related displays in Stellarium lags BEHIND four hours, yet Seamonkey mail is being time stamped four hours AHEAD of real-time. Is Porteus accelerating the system clock to speed up apps somehow? I missed catching this anomaly when I first installed Porteus but now that I noticed this I have to put it off using Porteus for Puppy or just don't use Porteus for Seamonkey mail because I don't want mail with erroneous time stamps naturally. These separate apps being time affect so suggests that somehow apps are misreading the system's real-time clock.

root@porteus:~# date
Fri Oct 25 12:55:37 UTC 2013
root@porteus:~# time

real 0m0.000s
user 0m0.000s
sys 0m0.000s
root@porteus:~#



Jim in NYC

jimwg
Shogun
Shogun
Posts: 322
Joined: 09 Oct 2013, 18:15
Distribution: porteus
Location: NYC

Re: Possible Time Stamp Shifting Between System Time And App

Post#4 by jimwg » 29 Oct 2013, 21:16

Time shift issue confirmed by some Mint mavens using assorted apps so where can I notify Porteus programmers? Thanks for a tip!

Jim in NYC

User avatar
wread
Module Guard
Module Guard
Posts: 1255
Joined: 09 Jan 2011, 18:48
Distribution: Porteus v5.0-kde-64 bits
Location: Santo Domingo
Contact:

Re: Possible Time Stamp Shifting Between System Time And App

Post#5 by wread » 29 Oct 2013, 22:22

@jimwg

Your clock is not set correctly if you hover your cursor over the clock and it does not show Local time and UTC correctly at the same time....
It is not easy; follow the directions as explained in the posts related to TOR.

I am in Santo Domingo, we have the same time as in N.York EST. I hover the cursor over the clock and it says Santo Domingo:6:30 PM, UTC:10:30 PM. :D

My stellarium shows local time and the sun is under the horizon already; venus is south-west the most brilliant point in the sky.
Porteus is proud of the FASTEST KDE ever made.....(take akonadi, nepomuk and soprano out and you will have a decent OS).
The Porteus Community never sleeps!

jimwg
Shogun
Shogun
Posts: 322
Joined: 09 Oct 2013, 18:15
Distribution: porteus
Location: NYC

Re: Possible Time Stamp Shifting Between System Time And App

Post#6 by jimwg » 30 Oct 2013, 03:23

wread wrote:@jimwg

Your clock is not set correctly if you hover your cursor over the clock and it does not show Local time and UTC correctly at the same time....
It is not easy; follow the directions as explained in the posts related to TOR.

I am in Santo Domingo, we have the same time as in N.York EST. I hover the cursor over the clock and it says Santo Domingo:6:30 PM, UTC:10:30 PM. :D

My stellarium shows local time and the sun is under the horizon already; venus is south-west the most brilliant point in the sky.
Checking this out. Might be everyone's oversighted the system's UTC settings which Mint doesn't have. As you mentioned it's a difficult procedure. Dunno, I'll report on this.

Jim in NYC

User avatar
fanthom
Moderator Team
Moderator Team
Posts: 5666
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland
Contact:

Re: Possible Time Stamp Shifting Between System Time And App

Post#7 by fanthom » 30 Oct 2013, 06:51

maybe stellarium does not read the system time correctly? please go to http://www.uize.com/examples/digital-clock.html and check if the time displayed by the clock is the same as in your system.
Please add [Solved] to your thread title if the solution was found.

User avatar
wread
Module Guard
Module Guard
Posts: 1255
Joined: 09 Jan 2011, 18:48
Distribution: Porteus v5.0-kde-64 bits
Location: Santo Domingo
Contact:

Re: Possible Time Stamp Shifting Between System Time And App

Post#8 by wread » 30 Oct 2013, 12:32

My Stellarium, version 0.11.4 which I posted in this forum, reads the local time correcly....
Porteus is proud of the FASTEST KDE ever made.....(take akonadi, nepomuk and soprano out and you will have a decent OS).
The Porteus Community never sleeps!

jimwg
Shogun
Shogun
Posts: 322
Joined: 09 Oct 2013, 18:15
Distribution: porteus
Location: NYC

Re: Possible Time Stamp Shifting Between System Time And App

Post#9 by jimwg » 30 Oct 2013, 14:11

Greetings!

Issue is this:

Forget Stellarium.

The far more important app being affected is Seamonkey Mail (or maybe any other mail app) in regards to the date/time of mail being displayed.

It's 08:30 AM New York. Using Porteus Date and Time Settings Panel, when the "My System clock is set to UTC/GMT No Time Zone Specified", the neighboring pane reads "Your clock will now display the time as 09:30 AM", the same time on my Orage Panel Clock and real time -- BUT my latest SeaMonkey Mail is coming in as time-stamped at 12:30 PM -- in fact the whole mail time column is now advanced four hours ahead real time in the PM. When I now set the UTC Timezone as US Eastern, the "Now Displaying Time" panel now reads 04:30 AM (just incidentally exactly like Stellarium right now) yet Orage reads 08:30 AM real-time and SeaMonkey Mail now normally reads the latest mail as coming in at 08:33 AM real time at this moment. When I manually set the correct time with the set time feature -- which was reading four hours behind real time -- I lose that new setting on re-boot, and mail time stamp are still four hours advanced.

I don't know if this is a XFCE quirk influence (supposedly not having time settings of its own?) or whether or not Porteus Time Config panel actually locks in the time you set without changing it when you punch out; There's only a Cancel button there instead of Exit or Next, so a newbie would wonder whether in reality they're cancelling out their newest setting too. All I can say is something is going on that doesn't happen in Puppy or Mint with identical apps, and Mint mavens say it might be because Porteus doesn't directly access local time servers online to synch with against "BIOS" clock settings. You'd know more about that than I do, but I'd just like SeaMonkey users to help nip a possible problem in the bud and mess around with SeaMonkey and Proteus Time Settings and see if this mail time stamp issue pops up. The reason might also be why Stellarium - or maybe unknown other apps -- act quirky here too.

Thanks for any user input on this!

Jim in NYC

User avatar
Ahau
King of Docs
King of Docs
Posts: 1331
Joined: 28 Dec 2010, 15:18
Distribution: LXDE & Xfce 32/64-bit
Location: USA

Re: Possible Time Stamp Shifting Between System Time And App

Post#10 by Ahau » 31 Oct 2013, 16:13

Thanks, Jim!

This is an interesting problem and I'm trying to sort through it, though I haven't been successful as of yet. I pulled Stellarium for my 64-bit install in XFCE and it appeared to show the correct time (both the time display and the sun's position--I think, as I was mainly looking at the time display but the sun was down when I got on the bus and started coming up before I got off the bus, which matched reality!). I'll re-test in 32-bit to confirm.

I have, however, reproduced your issue with seamonkey mail. I sent myself an email to test at 7:06am local time (Pacific Standard) and Seamonkey showed it at 2:06pm (UTC). The message metadata showed both the 7:06 PST and the 2:06 UTC time, so my guess is that, since the system is set to localtime ("Factory" timezone, assumed as UTC) by default, Seamonkey thinks the system is set to UTC and it shows the UTC time rather than an offset. When you install your other OS's (puppy and Mint), do you specify a timezone?

The problem I run into with resolving this (which I ran into before when I was writing the time config application) is that if you select "localtime" and set a timezone on a Slackware system, it adjusts your system clock (i.e. it will change the setting in your BIOS) to the current UTC time and applies the timezone offset in 'date', the panel, seamonkey, etc. I did not write in the ability to do this in the GUI application because IMO a portable OS should not mess with the BIOS clock.

The paragraph above may not make a lot of sense on your first read-through. To understand a little better, fire up Porteus, open a terminal and login as root. Then run 'timeconfig'. This is a Slackware ncurses dialog to select a timezone. Select "localtime" and then choose your timezone. Assuming it is 1pm in New York, your panel will still read 1pm and Seamonkey will show a new email coming through at 1pm, but your system clock will be changed to 5pm. Then, if you reboot into another OS, the time will be off by four hours in that OS. I don't understand why it's handled this way, but that's what happens to me when I do it. I'm thinking the other OS's have a way to set a timezone without monkeying with the system clock. I'm going to dig in a little deeper and see what I can come up with. It's easy for me to blame this on Slackware rather than myself, but I typically find that when my opinion varies from Pat's, I'm the one who is at fault!

Note that when I applied fanthom's KDE patch that included /etc/localtime (the fix for TOR browser), this did not appear to fix the time shown in seamonkey, but I didn't reboot with that module active, so I'll continue testing. You could probably work around this by setting your system clock to UTC time and then telling all of your OS's that it's set to UTC and needs to be offset for your local timezone, but I'd rather have a fix that doesn't obligate the user to do that.

Also, when I run the 'timeconfig' utility and go to set the time, I have back, cancel, and apply buttons; the apply button is grayed out until you make modifications. If you don't have this button, please take a screenshot and post it or send it to me and I'll get it fixed.

Thanks again!

EDIT: I found some interesting info here: http://www.linuxquestions.org/questions ... 175451045/
I'll see if I can make sense of it all :)
Please take a look at our online documentation, here. Suggestions are welcome!

User avatar
wread
Module Guard
Module Guard
Posts: 1255
Joined: 09 Jan 2011, 18:48
Distribution: Porteus v5.0-kde-64 bits
Location: Santo Domingo
Contact:

Re: Possible Time Stamp Shifting Between System Time And App

Post#11 by wread » 31 Oct 2013, 19:42

@jimwg
I see you could get both local and UTC times to show correctly, but lost the setting at next reboot :x
It is my fault, as I forgot to write, you should copy the file /etc/localtime to rootcopy/etc/localtime, so the next time you reboot you will have it right. :)

Enjoy!
Porteus is proud of the FASTEST KDE ever made.....(take akonadi, nepomuk and soprano out and you will have a decent OS).
The Porteus Community never sleeps!

User avatar
Ahau
King of Docs
King of Docs
Posts: 1331
Joined: 28 Dec 2010, 15:18
Distribution: LXDE & Xfce 32/64-bit
Location: USA

Re: Possible Time Stamp Shifting Between System Time And App

Post#12 by Ahau » 31 Oct 2013, 19:58

I think wread is correct, and I got a note from fanthom that helped me put some things together -- the hardware clock gets set to match the system clock on shutdown, this is why the clock gets messed up when you set the system to localtime with a timezone.

Please try the following, which appears to have fixed stellarium (I think I was wrong about it working correctly in the first place) and the timestamps in seamonkey on my end:

First, create a clean work location to create a new module, add rc.6 and modify it to prevent it from mucking with the hardware clock (this will likely become standard in the next version of Porteus):

Code: Select all

#change to root user first!
mkdir -p /tmp/timezone/etc/rc.d
cp -ar /etc/rc.d/rc.6 /tmp/timezone/etc/rc.d
geany /tmp/timezone/etc/rc.d/rc.6
*note - if you are using a DE other than LXDE or XFCE, you may not have geany installed. use your favorite text editor instead.

now, comment out the lines that modify the hardware clock, like so:

Code: Select all

# Store systemtime to hardware clock:
#grep -wq rtc /proc/ioports || CLOCK_OPT="--directisa"
#grep -wq "^UTC" /etc/hardwareclock && CLOCK_OPT="$CLOCK_OPT --utc" || CLOCK_OPT="$CLOCK_OPT --localtime"
#hwclock $CLOCK_OPT -w
save and exit your text editor.

Now, run 'timeconfig' in your terminal. Select "No Hardware clock is set to local time", then choose your timezone from the list. When that's done, you'll copy these new settings into your module directory:

Code: Select all

cp -ar /etc/localtime* /tmp/timezone/etc/
cp -ar /etc/hardwareclock /tmp/timezone/etc/
then you can build your module and put it in your modules folder:

Code: Select all

cd /tmp && dir2xzm timezone timezone.xzm
cp timezone.xzm /mnt/live/porteus/modules
Open up the rc.6 on your live system:

Code: Select all

geany /etc/rc.d/rc.6
and once again comment out the hardware clock stuff (this is so it won't change the hardware clock when you reboot one last time without the timezone module active).

Now, reboot (without saved changes -- these files won't be applied if you have something in your saved changes precluding them), verify that timezone.xzm got activated (ls /mnt/live/memory/images), check your mail and stellarium, and let me know what happens. Note that the time in your panel clock may show an offset before you reboot for the first time. I'm not sure why, but it worked for me after I rebooted (though my steps were in a slightly different order than what I've described here).

One quirk -- on my system, the system and hardware clocks are still not in agreement:

Code: Select all

root@porteus:/tmp# date
Thu Oct 31 12:56:43 PDT 2013
root@porteus:/tmp# hwclock -r
Thu 31 Oct 2013 05:56:48 AM PDT  -0.408113 seconds
root@porteus:/tmp# 
So I'm still at a bit of an impasse with regards to implementing a full fix in the application, because any time you run hwclock to set the hardware clock to match your system clock, it will offset things again...grr...
Please take a look at our online documentation, here. Suggestions are welcome!

User avatar
wread
Module Guard
Module Guard
Posts: 1255
Joined: 09 Jan 2011, 18:48
Distribution: Porteus v5.0-kde-64 bits
Location: Santo Domingo
Contact:

Re: Possible Time Stamp Shifting Between System Time And App

Post#13 by wread » 31 Oct 2013, 20:11

Do as I say and you won't miss it!

Losing settings at reboot is a Porteus feature.....
You can use changes to get time right or use AF mode and put your changes in rootcopy by hand.

Don't mess with the system, it is ok... (at least mine!)

Regards!
Porteus is proud of the FASTEST KDE ever made.....(take akonadi, nepomuk and soprano out and you will have a decent OS).
The Porteus Community never sleeps!

fi5ban
White ninja
White ninja
Posts: 15
Joined: 23 Oct 2013, 20:02
Distribution: latest
Location: Nebraska,USA

Re: Possible Time Stamp Shifting Between System Time And App

Post#14 by fi5ban » 04 Nov 2013, 01:02

I am only seeing this issue in razor myself xfce and mate seem to hold time just fine

jimwg
Shogun
Shogun
Posts: 322
Joined: 09 Oct 2013, 18:15
Distribution: porteus
Location: NYC

Re: Possible Time Stamp Shifting Between System Time And App

Post#15 by jimwg » 05 Nov 2013, 00:05

Greetings,

I apologize for not logging in this topic or anywhere lately due domestic situations. As a total techie newbie I'm finding it rough going following thru all your recommendations but will give them a college try! Hopefully the "fix" will be implemented so it's completely invisible to other newbies or any surfers out to taste a new OS. Will report shortly.

Jim in NYC

Post Reply