Hardware clock & timezone issues

[greengeek]

I apologise for the lengthy post - but timezone and system clock issues can be confusing and I would like to offer some thoughts, questions, and some tools to investigate the relationships between hardware time, system time, browser/server time and user timezone.

For a long time I have had issues with Puppy's system clock not matching the "timestamp" of my browser.

One impact of this is that sometimes my browser is unable to download email attachments from the server - and I see an error message saying that there is an "invalid token".

Maybe my timekeeping issues relate to the fact that I live close to the international date line - if my timezone shifts a little to the west my browser thinks I am moving closer to Australia and still happily downloads my email attachments. But if my browser timezone drifts an hour to the East it crosses the dateline and shifts me into an entirely different day - which upsets the email attachment server.

During Quicksetup I have two timezones applicable to me - Pacific,Auckland or GMT+12 Wellington,Fiji. In theory (my theory anyway...) these two timezones should be pretty much the same thing (at least in winter).

However, the last Puppy that correctly handled the GMT+12 Wellington timezone was Slacko 5.6 - a long time ago. Since then there have been a variety of mismatches between my bios (hardware,RTC) clock and my soft (system) clock as a result of timezone choice and other factors. Some of this is due to bugs in Puppy, some of it is due to my lack of knowledge, but I suspect that some is due to general misunderstanding around how Linux handles the PC hardware clock. And some of the browser/server issues are related to the different ways in which different browsers calculate the system time on the users machine. Chrome and Mozilla use different methodologies in the past and may still do.

So what goes on between my hardware clock and my software clock and timezone settings? How can I stabilise my system? What data can I find out?
(During my daily use and also during these tests i keep the Bios/RTC/Hardware clock set to my local time. ie: when the sun is about to reach its midday peak my hardware clock says 11.59am. True "local, physical, solar" time)

Firstly - what does my browser think the time is?

We can visit the following site to find out:
http://browserspy.dk/date.php

Here is a comparison (Using Tahr32) between what my browser thinks is different between the Pacific,Auckland timezone and the GMT+12 Wellington timezone.

browsertime.jpg (81.76 KiB) Viewed 1288 times

.
Notice the differences in "TimeZone offset" and also note the difference between server time and my browser time (measured in seconds). I think this is what upsets my email server when I am set to GMT+12. (There should be no difference - or at least minimal difference between Auckland and Wellington/GMT+12 timezones)

So I decided to look more closely at what my software thinks about my hardware clock.

There seems to be a command "hwclock" with which we can interrogate the bios/RTC clock in the PC. Take care with this command as it is also able to change the bios clock settings.

Here is what I see when I boot into Pacific/Auckland time

Code: Select all

root# hwclock
Fri 04 Jun 2021 08:53:07 PM NZST  -0.402524 seconds 

And here is what I see when I set GMT+12:

Code: Select all

root# hwclock
Thu 03 Jun 2021 08:53:41 PM -12  -0.683680 seconds

But here is what my actual bios clock says during the boot process:

BiosTime03.jpg (16.92 KiB) Viewed 1288 times

.
It's obvious that in this case hwclock is NOT showing me the real time that is ticking away at a hardware level.
So it seems that Linux does not really care what your bios clock says. It does not treat it as a fixed point in space/time.

I have seen much advice that it is useful to tell Puppy to use UTC - but that only seems like useful advice if your PC is always on the internet. These days there is a checkbox in the Quicksetup menu where we can force Puppy to use UTC. But what value is this for users not online? Is UTC necessary?

My assumption has been that if I leave UTC unticked then Puppy will assume that we are running with the hardware clock set to local "physical, solar" time.

Unfortunately that seems to NOT be the case. If we do not specifically force Linux to treat the hardware clock as either UTC or "Localtime" then it just flounders around ignoring the hardware clock and allowing software to do it's own thing.

Maybe the Quicksetup routine needs to have a "localtime" checkbox and the new user must be forced to decide which they want.

Here is an excerpt from the hwclock manual:

Options
The following options apply to most functions:
-u, --utc
--localtime
Indicates that the Hardware Clock is kept in Coordinated Universal Time or local time, respectively. It is your choice whether to keep your clock in UTC or local time, but nothing in the clock tells which you've chosen. So this option is how you give that information to hwclock.

If you specify the wrong one of these options (or specify neither and take a wrong default), both setting and querying of the Hardware Clock will be messed up.

If you specify neither --utc nor --localtime , the default is whichever was specified the last time hwclock was used to set the clock (i.e. hwclock was successfully run with the --set, --systohc, or --adjust options), as recorded in the adjtime file. If the adjtime file doesn't exist, the default is local time.

Windows dual booters in particular may have problems with clock stability.

So what about timezone setting? This can obviously upset browser time and impact your connection to websites and email etc. Although browsers nowadays can increasingly use geolocation and other factors to confirm where you are and to sync you appropriately with servers.
One thing that can upset email servers is privacy settings in the browser. Here is one link that offers a piece of code that can be entered into Firefox devmode to analyse whether or not there is fingerprint rejection masking the timezone of the user:
https://support.mozilla.org/en-US/questions/1198372
Turns out this was one of the problems I had when testing the latest Slacko/Firefox combo even though I had never heard of fingerprint privacy options.

And should the tray clock popup correctly identify the timezone? If I select GMT+12 my tray clock says -12:

trayclock.jpg (21.52 KiB) Viewed 1288 times

.
So here is what I think my problems have been:

1) I assumed that Linux cared deeply about the hardware clock. It doesn't. It is my responsibility to tell Puppy to reference my hardware clock as localtime if that is what I want.

2) Some (many) Puppys have incorrect GMT timezone data in the zoneinfo Etc files. It seems that hwclock adds the timezone data on to the bios clock value to determine system time. If the timezone file is wrong then our system clock is wrong - regardless of the accurate setting of the hardware clock.

3) The timezone reflected when I hover over my tray clock should match with my timezone choice. If I choose GMT+12 in quicksetup then the tray clock popup should reflect that. If it shows "-" instead of "+" then either i have chosen the wrong timezone, or the zoneinfo/Etc timezone file is wrong, or there is some coding somewhere that is mixing things up.

Keen to hear any info that advances my understanding...

EDITs :
The man for RTC includes more complex info which also talks about accessing data from the "first read" of the rtc by using the command cat /proc/driver/rtc. Here is some data from Slacko 8.2.1 I am trialling:

Code: Select all

~$ cat /proc/driver/rtc
rtc_time	: 11:15:02
rtc_date	: 2021-06-04
alrm_time	: 08:53:42
alrm_date	: 2021-07-04
alarm_IRQ	: no
alrm_pending	: no
update IRQ enabled	: no
periodic IRQ enabled	: no
periodic IRQ frequency	: 1024
max user IRQ frequency	: 64
24hr		: yes
periodic_IRQ	: no
update_IRQ	: no
HPET_emulated	: yes
BCD		: yes
DST_enable	: no
periodic_freq	: 1024
batt_status	: okay
~$ 

At least that command seems to know that it is morning - which hwclock does not:

Code: Select all

~$ hwclock
2021-06-04 23:21:34.310697+12:00
~$ 

Other good reading :
https://tldp.org/HOWTO/Clock-2.html

[GMBudwrench]

On a related note, is there a way to convert a Puppy to display 12 hour; ie 1 pm instead of 24 hour time: 13:00? I’m not in Puppy atm, but doesn’t Fossapup display 24 hour mode?

[williams2]

The time now is 23:32 UTC https://time.is/UTC

Your local time is 11:32 NZST https://time.is/NZST
The webpage says: Currently New Zealand Standard Time (NZST), UTC +12
UTC+12 means your local time is 12 hours later than UTC

The time zone data file is referring to the number that must be added to the local time to get UTC.
In your case, that number is -12
For example, 11:32 NZST + (-12) is 23:32 UTC

If you type this in a text terminal:

Code: Select all

echo $TZ
TZ=NZ date
TZ=NZ-12 date
TZ=NZ+12 date

I think that TZ=NZ date and TZ=NZ-12 date should both display the correct time, assuming the RTC real time hardware clock is set correctly.

[TerryH]

Currently in Slacko64 8.2.1, so had a play with timezone. I also set my HWClock to Local time. When set to GMT +12, it does appear to be a bug in displaying -12, as the time displayed is correct for what is GMT+12.

One thing to note is that when you use GMT -/+N for the timezone, the system I believe won't adjust for Daylight savings if you are in a location which does adjust clock times. If you use the place or region specific zones, in your case Pacific/Auckland, the clock will auto adjust for change over. The checks shown below indicate you may be better off selecting Pacifc/Auckland.
I set my time to GMT +12

Code: Select all

~$ date
Fri Jun  4 13:21:39 -12 2021
~$ hwclock
2021-06-04 13:21:45.467970-12:00
~$ TZ=UTC date
Sat Jun  5 01:21:54 UTC 2021
~$ 

Note: Interesting that the UTC time above is actually shown here as 1 day ahead of actual UTC time, it should show Friday Jun 4. This helps in explaining why the correct system is shown with -12.

I then changed to Pacific/Auckland. Now all output is being shown as expected:

Code: Select all

~$ date
Fri Jun  4 13:23:18 NZST 2021
~$ hwclock
2021-06-04 13:23:32.077359+12:00
~$ TZ=UTC date
Fri Jun  4 01:23:46 UTC 2021

[ozsouth]

@GMBudwrench - for me, this works - rightclick taskbar time, then click clock format, then drop down clock format option, set & apply.

[JASpup]

simple commiseration post:

I happen to be on the same issue. For a start, Tor requires psync, timezone w/Hardware clock set to UTC, and I believe I click a "time from Internet" checkbox when it is present (happens to be missing from X-Tahr quicksetup).

On my XP laptop Internet bandwidth is so low, Tor is not an option, and for any such machine I'd just as soon have the clock set, but can only do so manually. I am not easily able to set the time from Internet.

Otherwise of course, I'm always looking at the wrong time in order to use Tor.

[bigpup]

On a lot of computers I run Puppy on.
The hardware clock does not keep good time.

I always set the time to synchronize to a public time server on startup.

The bios battery getting low on power, can cause the hardware clock to not work well.
Actually, this battery can cause a lot of issues, if it is low on power.
If the battery is older than 5 years.
It does need replaced with a new battery.

[baldronicus]

Hi @greengeek . I don't know whether any of the following might be of any help, or not. I don't understand much of this.

From the times that you have posted I get the impression that Puppy might still be applying a UTC adjustment to your local time even though you have not selected UTC. Essentially adding 12 hours to your real time.

The hwclock entry that you quoted mentions that it will use the parameters in the adjtime file, if it exists.
This leads to two questions:
Could you be using a save file where UTC had been used at some point (in a test, or something)?
As developers are likely to be generating the system in an environment where UTC is in use, can you find an adjtime file that already exists? (I have started writing this before checking a Puppy)?

The use of UTC is not just for the net. Almost all of the machines that I use (most of which are off-line) use UTC, simply because I have found it easier after getting caught up in a time issue before. That includes some dual-boot Windows XP machines where XP is just used for old games and, maybe accessing an old utility. I just ignore the incorrect time shown in XP. The important thing to me is that the time (even if displayed incorrectly in one OS) is consistent for system stability.

That is, of course, fine for me, but I also understand that there are different considerations for other users, particularly where the data you might be accessing is important.

The following probably is redundant and won't help with your queries (please just ignore it if that is the case) .
My understanding/interpretation of the following might be incorrect. Hopefully someone with more knowledge will correct things if that is the case.

UTC (if you can/ decide to, run with it) is based on the time at some place near Greenwich in the UK. It is it's reference point if you like. Unless you are accessing a network time server, or the like, then the system is going to use the BIOS/system etc. clock to provide an estimate of that time (near Greenwich).

New Zealand is, I think, normally 12 hours ahead of Greenwich time (i.e. GMT +12 hrs).
Hence, for New Zealand, the BIOS/system clock would need to be set so that it is [local time -12 hrs] (unless Daylight Saving is used in NZ, and is active at the time of setting the clock). Once the NZ locale information is provided, the system will calculate and display the local time (BIOS/System/estimated time near Greenwich +12 hrs).

Although it seems more involved, the use of UTC has the advantage of greater flexibility, especially if you are traveling across time zones, or if Daylight Saving is used in your area.

As an example, let's pretend that I am standing, with a laptop set to use UTC, next to the border of Queensland (QLD) and New South Wales (NSW) in Australia, and that Daylight Saving is active in NSW, and that I could step across the border and change my system locale in no time at all (not likely with me ).

Say current local time in QLD is 11:00am (AEST: GMT+10). As I am using UTC, the BIOS/system clock is set to 1:00 am (11 (local hrs) - 10 (GMT adjustment)) on the same day. However, the time displayed in the OS is 11:00 am, the correct local time.

The current local time in NSW is 12 midday (AEDT: GMT+11) due to Daylight Saving.

I step across the border and update my locale to NSW. The BIOS/system clock is still set to 1:00 am. However, the OS now shows the time as 12 midday, the correct local time in NSW.

Across the border we go again, back into QLD, with another update of locale. The BIOS/system clock is still set to 1:00 am. The time displayed by the OS has reverted to 11:00 am, correct local QLD time.

The important thing with the above is that we are not changing the BIOS/system clock. It remains a fixed estimated reference to the time in the place near Greenwich.

Of course if you are not using UTC, but the system thinks it is, then it will add the adjustment to the local time rather than the reference time in the place near Greenwich, messing things up.

As per Terryh's advice using the Pacific/Auckland time might be best as it also mentions NZST.

EDIT [I should have read williams2's post again]. You can tell I don't know anything about this!!!! Thanks.

[baldronicus]

Hi again @greengeek . Apologies for yet more waffle.
I have booted into Slacko64-7.0 with pfix = ram, didn't select UTC, and the displayed system time is ten hours earlier than the present (as expected, since I am normally using UTC on this machine). That is, it is showing the BIOS/system time setting correctly. I haven't downloaded Slacko 8.2.1 yet.

It looks like the file to actually check could be /etc/clock, which is a text file. In this system it is reading as HWCLOCKTIME='localtime'. Note the words "could be" as this is just the first file I found that seems to be relevant.

I don't how it might read on your system.

Thanks.

[gyrog]

Part of the confusion here may be due to the "TZ" variable itself.
It's offset number has to be the opposite of what you might expect.

In Queensland, Australia, the local time is GMT+10 but to set this with the TZ variable I specify "TZ=AEST-10", this works.
Note: Only the signed number in the "TZ" variable is used.

In Puppy on first-boot I always set the timezone in the "Country" part of "Quick Setup".

[greengeek]

@everybody - thanks heaps for the posts. I am working through each one to make sure I understand all this.

@baldronicus - thanks for the heads up to the /etc/clock file. In my case the contents confirm that my Puppy is treating my bios clock as my local time (which I was not 100% certain of).

Now that I know Puppy is viewing my RTC as localtime it allows me to confirm a bug I am experiencing.

I would like to ask anyone who has time to try a test please:
Boot a puppy without savefile (ie boot a pristine pup to the point where Quicksetup is displayed) and run the following two commands:

#cat /proc/driver/rtc

#hwclock

The output of these commands confirms that Puppy's "rtc clock" and "hardware clock" are not the same thing.

I mistakenly thought they were the same.

Apparently Linux only looks at the RTC once during booting and thereafter ignores the RTC and counts it's own software clock - which it calls it's "hardware clock" as revealed by the hwclock command.
(hwclock data seems to be made up of the RTC value skewed by the timezone)

Confusing.

If Puppy used the RTC value as the basis for timekeeping I would have no problem. But Puppies often use a faulty timezone file instead. (I notice this because I live next to the dateline and have no savefile so rely on Quicksetup to get my software time and browser time correct).

In which case I think it is a mistake for Quicksetup to start up with a pre-determined timezone displayed. Many Puppies have bugs in which zoneinfo/Etc file is selected.

I think Quicksetup should probably do the following:

1) Display the value of the RTC and encourage the user to check it.
2) Avoid displaying Perth, Los Angeles etc as the predetermined timezone - and display only GMT instead. (If there has to be a default)
3) Give the user 3 choices:
- i) Correct your RTC to match your local time
- ii) Change the RTC to match GMT (UTC) time (probably the safest as it potentially avoids a number of software bugs involved in timekeeping)
- iii) Ignore the RTC completely (due to dead battery or non-functional RTC) and specify the time manually or from timeserver.

I think it is critical for the user to understand that the RTC is consulted once only - and after that all software timekeeping comes down to the users choices in Quicksetup. More coaching is required (especially for dual boot users).

Please compare the following two images.
The first one compares my RTC value and my hwclock value straight after a pristine boot. They are different - hwclock has been pushed 8 hours into the future - compared to my RTC.
If Puppy was treating my RTC as localtime then shouldn't the hwclock match it? Or is Linux pretending that every user lives in Greenwich? Is this why so many Linuxers suggest running in UTC only?
(also note the difference between Quicksetup timezone (+8) and the hwclock offset (-8) as gyrog was mentioning)

The second image shows a mistake that has crept in as soon as I choose GMT+12 Wellington via Quicksetup.
That second pic reveals that my RTC knows it is early morning but the hwclock (upon which my browser time is based) believes it to be the evening and the wrong day. Obviously Quicksetup chose the wrong GMT offset file. It pushed my system time backwards by 12 hours instead of forwards.
(Or am I once again misunderstanding all this...?)

rtc_versus_hwclock.png (76.16 KiB) Viewed 1056 times

.
And now the mismatch because of a faulty zoneinfo/Etc GMT+12 file:

GMT+12_rtc_versus_hwclock.png (43.63 KiB) Viewed 1056 times

.

[greengeek]

If you type this in a text terminal:

Code: Select all

echo $TZ
TZ=NZ date
TZ=NZ-12 date
TZ=NZ+12 date

I think that TZ=NZ date and TZ=NZ-12 date should both display the correct time, assuming the RTC real time hardware clock is set correctly.

I tried this test at 5.55am Saturday and got the following results:
(Currently set up with GMT+12 Wellington via quicksetup)

TZCompare.png (12.51 KiB) Viewed 1052 times

[williams2]

When it is 0:00 (midnight) in New Zealand,
it is 12:00 (noon) in Greenwich, UK. (GMT = Greenwich Mean Time)

When the sun rises in NZ, it will rise 12 hours later in UK.

From https://linux.die.net/man/3/tzset
"The offset string ,,, specifies the time value to be added to the local time to get Coordinated Universal Time (UTC)"

For NZ, the offset string is -12
When it is midnight in Greenwich it is noon in NZ,
12:00 + (-12) = 12:00 - 12 = 0:00 (midnight)

So, if /etc/adjtime is configured for localtime
and if the system clock is correct,
these commands typed in a text terminal should show the same correct date and time:

Code: Select all

# TZ=":NZ" date
Sat Jun  5 06:55:10 NZST 2021
# TZ=GMT-12 date
Sat Jun  5 06:55:12 GMT 2021

TZ=":NZ" configures it to use the file /usr/share/zoneinfo/NZ
/usr/share/zoneinfo/Pacific/Auckland is just a symlink to /usr/share/zoneinfo/NZ

TZ=GMT-12 configures it to use a fixed number of -12
It will not automatically change to -13 for Daylight Savings Time.

The GMT in TZ=GMT-12 can be any 3 letters, TZ=XXX-12 or TZ=YYY-12 would work the same.

TZ=GMT+12 or TZ=GMT12 will not give you the correct time, 12 is not the correct number. -12 is the correct number.

You can put export TZ=":NZ" in /etc/profile or /etc/profile.local or /root/.profile

/etc/localtime should be a symlink to the correct file in /usr/share/zoneinfo/
ls -l /etc/localtime

You can create the correct symlink like this:
ln -fs /usr/share/zoneinfo/NZ /etc/localtime or this ln -fs /usr/share/zoneinfo/Pacific/Auckland /etc/localtime

[williams2]

On my machine:

Code: Select all

# cat /proc/driver/rtc ;  hwclock --show ;  hwclock --get ; hwclock
rtc_time	: 15:37:46
rtc_date	: 2021-06-04
alrm_time	: 02:05:10
alrm_date	: 2021-06-05
alarm_IRQ	: no
alrm_pending	: no
update IRQ enabled	: no
periodic IRQ enabled	: no
periodic IRQ frequency	: 1024
max user IRQ frequency	: 64
24hr		: yes
periodic_IRQ	: no
update_IRQ	: no
HPET_emulated	: yes
BCD		: yes
DST_enable	: no
periodic_freq	: 1024
batt_status	: okay
2021-06-04 15:37:46.521564-0400
2021-06-04 15:32:20.501747-0400
2021-06-04 15:37:48.007575-0400

cat /proc/driver/rtc and hwclock show the same time.
AFAIK, on my machine, the bios clock, the kernels' rtc, and hwclock's rtc clock are all one and the same hardware.

hwclock --show displays the rtc time.
hwclock --get displays the rtc time, corrected by /etc/adjtime (my rtc hardware clock is fast by about 1.2 seconds per day, so it is about 5 minutes fast. /etc/adjtime corrects it automatically when setting the system clock from the hardware clock.)

If you have a time server on your network and the kernel can access it when booting, the kernel can set the system clock from the time server and can automatically keep the system time synced to the time server.

AFAIK, setting the system clock using hwclock stops the kernel from setting the system clock from a network time server.
AFAIK, most Pups set the system clock using hwclock.

[williams2]

Sorry, I forgot the correct syntax for TZ

TZ=NZ is not correct. The correct syntax is TZ=":NZ"

[bigpup]

First question.
Is the internal clock time set correctly in the computers bios or UEFI setup?

[greengeek]

First question.
Is the internal clock time set correctly in the computers bios or UEFI setup?

Yes, it is set up to match my exact date and time. (Currently winter here so no variations for summer time. My RTC clock time reflects absolute normal time)

[baldronicus]

Hi again @greengeek . I checked a book (that I have never finished) and found the following:

"All x86 and x86_64 computers include a clock on the motherboard to keep the time while the computer is shut down."
"Before you set your clock, though, be aware that Linux keeps time based on Coordinated Universal Time (UTC), which is closely related to Greenwich Mean Time (GMT). If your computer boots only Linux, your best bet is to set the motherboard's clock to UTC/GMT." A link to obtain the current GMT time is given, however, this is an older book, so I don't know if the link would still be valid. "If your Linux installation currently works, though, you might do well to not adjust your motherboard's clock, even if it's set for local time; such a change would necessitate a change in your Linux configuration." (They are talking about a larger Linux set-up here).
"If your computer boots both Linux and an OS that keeps it's time as local time, you can set the hardware clock to local time and Linux can make the adjustment internally."
There is some description of hwclock. Then "Ordinarily you don't need to use these commands,although they are used in system startup and shutdown scripts to set the software clock from the hardware clock when booting and to set the hardware clock from the software clock when shutting down."

I don't know if this helps with things. It does suggest to me that yes, the system only uses the BIOS/motherboard clock time as a starting reference and then uses it's own internal software system clock (maybe based on the CPU to an extent???) to maintain time whilst running, then updates the motherboard clock on shutdown. It makes sense that you would have one basis for calculating time in the running system. From above, in Linux the time is based on UTC. Hence, if local time is used, it makes an initial adjustment to bring the local time into alignment with UTC. I think this might relate to the adjustments that williams2, terryh, gyrog etc. have mentioned.

Hopefully they, or others, might correct things if I have it wrong. Thanks.

[greengeek]

"hwclock" is obviously critical in terms of reporting and adjusting the system clock and synchronising RTC and system clock.

But there seems to be a conflict in terms of understanding how it works.
(Maybe this explains why I see different behaviour on different Pups)

One website reports that hwclock defaults to localtime:
https://linux.die.net/man/8/hwclock

DefaultLocaltime.png (149.45 KiB) Viewed 980 times

.

But another website reports that hwclock defaults to UTC:
https://www.man7.org/linux/man-pages/ma ... ock.8.html

DefaultUTC.png (72.93 KiB) Viewed 980 times

.

This website suggests that there has been a change in hwclock version level:
https://forums.gentoo.org/viewtopic-t-1 ... art-0.html

hwclock_defaults_change.jpg (26.03 KiB) Viewed 971 times

.

It seems that hwclock may have gone through some significant changes in 2015 so I wonder if puppy's clock based functions have kept pace with any changes.

I have seen some weird stuff with the behaviour of the zoneinfo/Etc GMT+/- files so maybe the hwclock version could be a contributor.

I think I will try to compare hwclock versions in my Pups and I would be keen to know what other versions are in which pups.

Maybe these issues are not so visible to people living in timezones further away from the +/-12hour cusp? But it is annoying me why I can't pin down why GMT+12Wellington behaves so differently from Pacific, Auckland in various versions of Puppy.

[amethyst]

@greengeek - Consider moving to a more convenient timezone.

[Grey]

My clock got lost all the time(by three hours) when I used both Windows and Linux at the same time. But when I completely switched to Puppy and set the clock to UTC, the problem disappeared

[baldronicus]

Hi @greengeek . I was hoping to test some stuff before posting, but it hasn't happened, so I thought I should mention some stuff before I forget.

First off, it is my understanding that, in the Slacko 8.2.1 thread, 01Micko has acknowledged (in response to your post) that there is a problem (in Woof-CE) with respect to the processing of the GMT (I think, maybe GMT +/-12) time entries. I think he has indicated that he expects these problems to be corrected in the next release of Slacko (which would mean that they would be corrected in Woof-CE, I imagine).

I get that you want a greater understanding, and want to solve the differential with respect to the treatment of the Auckland NZST (I have forgotten the title of the full entry) and the GMT +12 entries. The thing is I don't understand how the time system works in Puppy, and anything any of us try at the moment is going to be done in a known flawed environment that is not entirely working the way it should do. It is OK for most of us, but not in your situation. I can't help but feel that waiting to try the next release might be a wiser strategy.

That said, last night I did try looking at some stuff on a HP NC-2400 laptop. Unfortunately that machine doesn't set the RTC time via the BIOS, but from the operating system, so I started to get myself caught up in "double-think" loops and hoops (I have enough trouble single-thinking ). I also managed to get myself confused with the different releases that I was trying out.

However, some stuff from a check of Slacko32-7.0 has struck me.

I suspect that the time settings applied to hwclock, and the time setup in general, might be being managed via a script, or something (at least in later Pups), so that the required variables might (at least after Quicksetup is run) always be given to hwclock etc., so that it never reverts to either the entries in /etc/adjtime (if it exists), nor to it's fallback defaults. It is, however, just a guess.

Hopefully someone with more knowledge will either debunk, confirm, or otherwise correct this theory.

When I booted Slacko32-7.0 using pfix=ram with a local time (not UTC) GMT+12 zone setting, it did not appear to have an /etc/adjtime entry.
The layout of the /etc/clock file seems to suggest to me that it is setup like a variable description (I am not a coder, so I can't be sure). That is: HWCLOCK="localtime" (from memory- I might have messed up the variable name).
I think /etc/localtime was symlinked (incorrectly, I think) to /usr/share/zoneinfo/etc/GMT-12. This is from memory so I could have the path etc. wrong.

I suspect that between the initial read of the RTC clock, the etc/clock variable setting, the binary contents of the relevant linked GMT or location file in usr/share/zoneinfo, (and maybe some other variables I don't know about), a script might setup the parameters for hwclock etc..

[Edit] I forgot about another file, next to /etc/localtime that is a symlink to a Factory file (binary, I think) that is in /usr/share/zoneinfo (maybe it is in the /etc subdirectory in that path).

As noted above, it is only a guess. I don't know. Thanks.

[greengeek]

I can't help but feel that waiting to try the next release might be a wiser strategy.

Thanks Baldronicus - I will certainly be keen to try the next Slacko release - but I also need to get a deeper understanding of the timezone and clock issues because they have been plaguing me for the last 5 years or more, throughout a variety of Puppies.

I can see now that Linux has changed it's behaviour somewhat during that time, and certainly Windows and Linux are diametrically opposed in how they look at the RTC so that has impacted my dual boot machines in a way I did not fully appreciate.

I am currently trying to assemble a chart comparing parameters between several pups (from Slacko 5.6 through to the latest Slacko and including Tahr/xenial and dpups of various ages) so that I can confirm my understanding.

The outcome might be that I switch to having my RTC set to UTC - but that's not the outcome I want as it doesn't solve some of the issues.
I would like to see consistent behaviour both before and after running Quicksetup (as I disable quicksetup on some of my Pups)

I really want my pups to respect my RTC until they are told otherwise.

I know that Taersh has done a lot of work to make timezone and clock behaviour consistent from the first boot without relying on quicksetup and getting to that point is still my goal.

Cheers!

[gychang]

If living in West coast, setting time zone to Los Angeles usually causes problems in puppy. Set it to US-Pacific.

[baldronicus]

Hi @greengeek . Please accept my apologies for [Edit- getting carried away again. I hadn't noticed that I was trying to climb onto a soapbox without even the excuse of having any knowledge. Thanks.]

[williams2]

Puppy Linux (or any Linux) can work with the hardware RTC clock set to localtime or set to UTC.

The correct offset for Auckland/New Zealand is -12
The correct offset for Auckland/New Zealand Daylight Saving Time is -13

-12 is correct.
+12 is not correct.
+12 is never correct.

Proof:

Code: Select all

# TZ=:Pacific/Auckland date
Sat Jun 12 15:00:19 NZST 2021
# TZ=:NZ date
Sat Jun 12 15:00:35 NZST 2021
# TZ=GMT-12 date
Sat Jun 12 15:00:41 GMT 2021
# TZ=GMT+12 date
Fri Jun 11 15:00:46 GMT 2021
#

Note that +12 displays the wrong date.
Note that :Pacific/Auckland, :NZ, and GMT-12 all display the same date and time.

For Auckland/New Zealand:
-12 is correct.
+12 is wrong.
+12 is always wrong.
+12 is never correct.

If you use GMT-12, you will need to change it to GMT-13 for Daylight Saving Time,
and back to Standard Time, GMT-12, each and every year.

[greengeek]

I set my time to GMT +12

Code: Select all

~$ date
Fri Jun  4 13:21:39 -12 2021
~$ hwclock
2021-06-04 13:21:45.467970-12:00
~$ TZ=UTC date
Sat Jun  5 01:21:54 UTC 2021
~$ 

Note: Interesting that the UTC time above is actually shown here as 1 day ahead of actual UTC time, it should show Friday Jun 4. This helps in explaining why the correct system is shown with -12.

Yes there seem to be two different ways of looking at time offset:

1) What is my timezone relative to GMT? answer: +12 (ie add 12 to GMT or UTC to find my local timezone)
2) What is my offset compared to GMT? answer -12 (ie to get GMT or UTC time subtract 12 from my localtime)

It seems to me that this dichotomy is at the heart of some Linux timekeeping weirdness. (Or at least i don't understand it yet...)

It seems that how the user accounts for time, and how the system and browser handle time are arse about. Pardon my french. Complete opposites.

Question: if my timezone is set to GMT +12 and I hover the mouse over the tray clock is it normal to see "-12" or should it be "+12" ?

ie: is it supposed to show timezone or offset??