[April 06] Volumio (2.390-2018-03-27) ROCK64 | [April 06] Q4OS (2.4-r3) PINE A64(+) Pinebook | [Jan 06] Arch Linux (20171225-1) PINE A64(+) Pinebook A64-LTS/SOPINE | [Jan 04] Linux (0.5.15-136) ROCK64 | [Jan 04] Android (20171204) ROCK64 | [Dec 22] Stretch Mate (0.5.15-136-20171222) ROCK64 | [Dec 21] openHAB 2 (v1.4) PINE A64(+)

Project Inspiration | Get Started | IRC Logs | Forum Rules/Policy

Timestamp offset
OK, I suppose I have a setting problem somewhere, but I don't see it. My Pinebook running Ubuntu (up to date) is doing something weird with file timestamps. I noticed it when copying files to and from another computer running Win10.

Here are the symptoms:

I created a text file on my PB, saved it, and copied it to a USB drive. PB tells me the timestamp on the USB copy matches the file on the PB, and both are what you would expect for a file just created and saved - close to PB system time reported. Then I moved the thumb drive to my HP and inspected the file. Windows Explorer tells me the timestamp is 8 hours into the future! Then I edited the file and saved it under another name on the HP and copied back to the thumb drive. Both the copy on my HP and the USB drive agree with each other and properly reflect system clock. I move the drive back to the PB. Now PB tells me the new file reads 8 hours earlier than its system clock. System clocks on both machines report the same time and date.

Another clue to what is going on is any file edited on the PB and copied to a USB drive will cause my Win10 machine to claim there is a problem with the drive and wants me to authorize a scan to repair. If I tell it to do so, though it reports no problem found, something changes as I can remove and re-insert the drive and it doesn't cause a repeat of the warning - unless the PB modifies the file.

Is this a bug in Ubuntu? Is there some setting somewhere in Ubuntu that I need to change?
"Get your facts straight first, then distort them as you wish." -- Mark Twain
It looks more to a Localtime/TimeZone issue, probably one of the devices is using localtime while the other using GMT as system clock.
Yep, the 8 hour offset value clearly points to GMT being used to timestamp files on the PB, but since the system clock knows it is in GMT+8, why wouldn't this propagate throughout the system? Whether a file is opened in system memory or the USB, the problem shows up. I suspect the GUI itself is the source of the problem, but why only on my machine (nobody else seems to be complaining about this.)
"Get your facts straight first, then distort them as you wish." -- Mark Twain
I presume that the issue is on windows side where your system clock isn't GMT but localtime. Check you BIOS clock settings...
No. First, research on the web shows a similar problem cropped up on a xenix system in Europe, where the offset was two hours, not eight. It was fixed by downloading some set of files. Further, I have two Win10 machines. Testing file stamping between the two machines with the same drive shows no disagreement on the time stamp.

To Review - The Key symptoms:

1. Time stamp interpretation and coding on the PB is 8 hours off the Windows machines (my time zone is +8).

2. Writing to the thumb drive on the PB causes the Windows machines to complain about a non-fatal directory error.

3. The problem doesn't manifest in two different Win10 machines. If there were a bios problem with one, the other would see it.

4. The same problem showed up on a Xenix machine in Europe in 2016, where it had a -2 hour time shift. Cured with a download.

I'm going back to the web page that mentioned the 2 hr problem and see if I can understand the details, but at the present I'm convinced something odd is going on with the PB. In the mean time, anyone tried this themselves? I'd like to see if it is easily reproduced, or is (more likely, I think) a setting problem with my PB. It took me a while to spot this, so I'm wondering if it isn't a matter of not looking for the behavior.
"Get your facts straight first, then distort them as you wish." -- Mark Twain

Forum Jump:

Users browsing this thread: 1 Guest(s)