NTP Server Time
-
dude if the time was off by 4 hours.. It would show in the system.. Its a stupid widget..
What does it show for time when you ssh in? and do date
-
Sorry can't answer what the date/time would be if I SSH into the box. Not running 2.4.X anymore, running 2.3.4. I no longer am having any time issues since reverting back to 2.3.4. But something is up with 2.4.X since it is going into my bios and changing the time. Date is correct but the time is being messed with.
-
If that was actually the case then forums would be blowing up with people reporting such a problem.
Your saying your bios time is being changed to be in the wrong timezone.. But the system widget shows the correct timezone and time. But the ntp status widget shows correct timezone but 4 hours off.. So 4 hours ahead of EDT.. ie New York… So UTC -1 What is that the freaking Azores?
Makes zero sense dude really...
-
I saw this same problem when updating 2.4.1 this morning. No issue with BIOS time being incorrect/reset, but NTP widget time is incorrect. Seems to be related to this redmine item:
https://redmine.pfsense.org/issues/7714#change-34352
-
Yeah I would say its related for sure..
// Have to convet the date to UTC time to match the PHP clock not the local client clock.
You an see that comment in the code.. So my guess is the OP clients timezone was off. Not sure how he was saying his bios time was being shifted… bios time should be in UTC... But depending on the OS - windows for example sometimes there can be problems when bios is UTC, etc. Believe there was a reg edit at one time for windows 7, etc.
its always difficult getting to the bottom of stuff when the OP doesn't post any actual info to work with... Like the status of his ntp server via ntpq etc. And what the system shows with date command.
What the php time is.. put a simple phpinfo.php file in /usr/local/www and then call it in your browser to see what php has the timezone set to, etc.
-
@ Johnpoz
Your saying your bios time is being changed to be in the wrong timezone.. But the system widget shows the correct timezone and time. But the ntp status widget shows correct timezone but 4 hours off.. So 4 hours ahead of EDT.. ie New York… So UTC -1 What is that the freaking Azores?Makes zero sense dude really...
Actually, it kind of does... I just think the poster is not doing a good job of explaining. Maybe I can shed some light on the issue and stay clear of the mud. Here goes nothing...
I have several computers, some desktops, some laptops, some servers, all from different manufactures (IE: Dell, HP, ASUS, etc). being used as workstations or servers depending on their role. Some of the systems have Microsoft (necessary evil as a result of my job) loaded as the OS while others have Linux (or BSD, etc. Example: pfSense on a Dell 7010, pfSense based on BSD. You get the idea.) OK here's where it gets funky:
On all of the systems if I access the BIOS and set time to the correct time for my timezone (Eastern) say for example 1:00PM prior to the installation of an OS. Then depending on the OS I install the BIOS time may "float". Let me explain. If I install the Windows OS, set the time and timezone within the OS, shut the system down or restart/reboot and access the BIOS, the time in the BIOS will show the same as the what is in Windows. However, if I install a Linux or BSD OS, set the date within the OS, shut the system down or restart/reboot and access the BIOS, the time in the BIOS will "float" ahead 4 hours (in my case as I'm in eastern TZ and the DST vs EST is now at -4 hours GMT). End result is the BIOS time "floats" to compensate for the actual time, being reported in the OS (IE: BIOS time now shows 5:00PM but because of my Eastern -4 hour GMT we get back to 1:00PM actual time reported within the OS). Thus giving the appearance the system is using a different TZ in the BIOS as a factor to calculate the time. It's totally weird! Why non Windows OSes do this I don't know, but from my findings they do regardless of the manufacturer (Dell, HP, ASUS, etc). I generally use Linux (actually prefer) more so than Windows so it's baffling to me why Linux (or BSD, etc) does it this way. And yes, when first transitioning away from Windows I went crazy fighting the BIOS time vs. the Linux OS time, now I don't even bother. What I do wish is that the non-Windows community would "fix" their time value (internal vs BIOS) so as to work more in keeping with the way Windows does it in order to avoid all this confusion. My findings are based on using steel systems and not virtual systems. I don't know if that makes a difference or not.
Hopefully what I described above makes some sense.
-
Yeah see my edit I was working before you posted. In the linux world you normally set your bios time to UTC… This is standard practice..
-
Mine is looking OK here.
That can I make a request that the NTP time widget include the GPS/PPS time stuff?
How do insert an image in the middle of my text and remove it from the bottom of my post?
I am used to using forum tools or just


-
"How do insert an image in the middle of my text and remove it from the bottom of my post?"
You can't with attachments. If you want an image inline with your post you would have to put in img tag and link to image hosted somewhere.
-
Thank you John.
Is there a way to display the GPS/PPS stuff in the NTP widget on the dashboard?
-
How do insert an image in the middle of my text and remove it from the bottom of my post?
Where's the problem with that?
I used the URL from one of your attached pictures and used it here with the {img} tag.
-
A bit of history: Back in 1980 the IBM PC came with MSDOS on 160K floppies. No room for TZ files. So MSDOS set its time directly from the CMOS clock. So generally you'd set that to local or "wall clock" time. When folks started porting the UTC based *nix to the PC, provision was made to deal will wall clock CMOS time so as to be able to dual boot nicely. For FreeBSD, the presence or absence of /etc/wall_cmos_clock was used to tell the kernel if the CMOS time was local or UTC. See FreeBSD's adjkerntz(8). Can't tell you how Linux does it, but presumably it has it's own method to coexist with DOS.
Checking my pFsense install ( fresh 2.3.x on an APU2) I don't see /etc/wall_cmos_clock, so presumably the pFsense default is to have the CMOS set to UTC. But perhaps the OP put pFsense originally on a box with local time in cmos and does have that file.
Now I haven't yet migrated my servers from FreeBSD 10 to 11, so don't know if FreeBSD made changes to the process. But possibly it has changed and pFsense 2.4 picked that up, and maybe that config is confusing the NTP Widget. Although why the NTP widget is looking at anything other than a NTP query and displaying UTC (NTP doesn't deal with local times at all) is beyond me. But given OP's NTP peer status his system is probably running time correctly. It would be worth looking at the system log after a boot to see if the "ntpdate" was jumping the time by 4 hours (assuming pFsense overrides the limiter). That would be a good indication of confusion between what the kernel thinks is in the CMOS and what actually is.