Wrong time of file creation

M

Minuel

Member
Joined
Mar 13, 2014
Messages
39
Reaction score
12
Country
Belarus
Dash Cam
Broken RX300 :( And new VIOFO A119
Hi!
I did not find a solution to the problem:
When creating a file, the creation name (date and time) is formed correctly, but the file creation time is additionally +3 hours
Time and time zone (+3 GMT) are set correctly. GPS module is present and enable. FW is last v3.91 Screenshot under the spoiler
wrong_time.webp
 
Last edited:
Minuel said:
Hi!
I did not find a solution to the problem:
When creating a file, the creation name (date and time) is formed correctly, but the file creation time is additionally +3 hours
Time and time zone (+3 GMT) are set correctly. GPS module is present and enable. FW is last v3.91 Screenshot under the spoiler
View attachment 41092
Click to expand...

is the camera mounted on a GPS module?
have you moved the camera between the creation of a *004 and *001 MP4 files?
 
borik said:
is the camera mounted on a GPS module?
have you moved the camera between the creation of a *004 and *001 MP4 files?
Click to expand...
1. Yes, the camera place on GPS module.
2. No, I don't moved the camera. This trouble is present from the time of purchase (February 2017) on older versions. The problem is the wrong time to create the file. (Red border). In the file name, the time is correct. (Green border)
 
Last edited:
I believe this has been talked about before. I think it computer related, not a firmware issue. I don't recall what thread unfortunately.
 
On my Windows 10 PC, the {Edit2: "Created" Date/time is the start time of a newly recorded file and changes when the microSD card file is copied to the computer. The "Modified" time is end Date/time of the newly recorded file and does not change when the microSD card file is copied to the computer.}
See also: https://dashcamtalk.com/forum/threads/a119-firmware.22223/page-38#post-399724
 
Last edited:
CaptureYourAction said:
I believe this has been talked about before. I think it computer related, not a firmware issue. I don't recall what thread unfortunately.
Click to expand...
It is not a computer related issue, it is definitely a firmware issue. No other camera I have screws up the timestamps, and I have a lot of cameras.
When I reported this before, I got a lot of push back from people saying it is not a problem.
It is a bug, it should be fixed.
 
5Cowbells said:
On my Windows 10 PC, the "Creation" time is the time when the camera file is copied to the computer. The "Modified" time is the original recording time I think. {Edit: If I examine the file properties of the microSD card file on the PC prior to copying the file to the PC, the Creation time is the same as the Modified time and matches Date/time stamp at the start of the video.}
See also: https://dashcamtalk.com/forum/threads/a119-firmware.22223/page-38#post-399724
Click to expand...
This is not the PC issue ! I tried on different PC's with different OS from Win XP to Linux. This is a screenshot original files of the SD card. This is the time of "Creation" original files on SD card (not copy) !
I see a double addition of 3 hours. The first 3 hours are local time GMT+3 (as in the name of the file) and an additional 3 hours in the creation time. Date/Time Stamp on video is correctly: GMT+3
 
Last edited:
DAP said:
It is not a computer related issue, it is definitely a firmware issue. No other camera I have screws up the timestamps, and I have a lot of cameras.
Click to expand...
Minuel said:
This is not the PC issue ! I tried on different PC's with different OS from Win XP to Linux. This is a screenshot original files of the SD card. This is the time of "Creation" original files on SD card (not copy) !
Click to expand...
I am re-examining this problem in more detail and have found some issues which I am currently working. So for now disregard my previous position in post #5 in this thread. I did try to clean it up a bit in the meantime but it does not explain all.
 
5Cowbells said:
I am re-examining this problem in more detail and have found some issues which I am currently working.
Click to expand...
I ran a test to observe what the Date, Date Created, and Date Modified columns displayed in the Details pane of the Windows 10 File Explorer app before and after being copied to the PC.

The following snips (screen shots) were taken off my Windows 10 PC File Explorer app, detailing three of the many Date/times that File Explorer can display. I chose to operate the camera {Edit: and the PC} in GMT 0 time during this test to avoid any confusion relating to time zone and daylight saving time. A set of files was recorded specifically for this test and one chosen for analysis. Here are the details of that recordings:
  • Camera ......................................................…………...……. A119 V1, Firmware V3.91, without GPS.
  • Loop recording time setting ...………………………… 3 minutes.
  • Parking Mode setting ….…………………………………. OFF.
  • Camera Time Zone .….…………………………………….. GMT 0, displayed time matches PC time within 2 seconds.
  • PC and app used for analysis ......…………………….. Windows 10 PC, File Explorer app.
  • Video File used for analysis (GMT)...…………………………... 2018_0829_021612_008.MP4
  • Start Date/time stamp recorded on Video (GMT) ...…… 20180829 02:16:10 (2:16 AM)
  • End Date/time stamp recorded on Video (GMT) ...…….. 20180829 02:19:10 (2:19 AM)
  • PC Date/Time when file copied (GMT) ….………………...... 20180829 03:06 (3:06 AM)

Snip1: Screen shot of Windows 10 File Explorer app displaying file details of the 2018_0829_021612_008.MP4 file(high-lighted) as it exists on the microSD card prior to copying it to the computer.

A119_microSD_file.webp



Snip2: Screen shot of Windows 10 File Explorer app displaying file details of the 2018_0829_021612_008.MP4 file (highlighted) after being copied to the PC.

A119_copied_file.webp



Observations and analysis:

There are numerous dates that can be displayed by File explorer (see "Add Columns" in the header View tab) at least some of which are embedded in the video file. I chose the three most common Date/times that I've seen in Windows; "Date", "Date Created", and "Date Modified".

From Snip1, for the high-lighted file as read directly off the microSD card:
  • The "Date" seems to match the Date/time stamp at the end of the video.
  • The "Date Created" closely matches the Date/time stamp at the start of the video and the Date/time embedded in the filename.
  • The "Date Modified" also matches the Date/time stamp at the end of the video.
From Snip2, the file details after being copied to the PC:
  • The "Date Created" changed to match the Date/time that the file was copied to the computer.
  • the "Date" and "Date Modified" columns did not change from that on the original microSD card file.
Also from Snip2, it was noted that unlike the analyzed file (in GMT), the previous older files on the PC, such as file 2018_0822_205728_071.MP4, show the "Date" column to read 7 hours earlier than the "Date Modified" column. These files were recorded with Time Zone set for Pacific Daylight Time (GMT - 7 hours). I doubled checked this by recording and analyzing a new file with my Time Zone setting (not documented here). So for files using a Time Zone setting:
  • The "Date" column for my time zone (Pacific Daylight Time, GMT-7) is seven hours earlier than the end Date/time of the original file recording in local time , but is the same as the video end Date/time when recording in the GMT (GMT 0) Time Zone. This is likely a Firmware bug since it makes no sense to me to display such a time. Presently, the Date/time displayed in the "Date" column is equal to the original video end GMT Date/time plus twice the Time Zone offset setting. @Minuel, this might be the problem you are experiencing.
  • The "Date Modified" time matches the original file end time, at least until the file is actually modified (a test for another day).
So @viofo, there does appear to be a problem with the "Date" data as viewed on Windows 10 File Explorer when a Time Zone other than GMT 0 is being used. Credits to @Minuel and @DAP for recognizing and insisting that there was a problem here. I only looked at the "Date Created" and "Date Modified" data in my previous posts so I missed the problem with the "Date" data.
 
Last edited:
I think what matters for purposes of an incident, or legal proof, is that the date/time stamp on the footage itself is correct, if the file name correctly corresponds with the timestamp (usually the start time of each file) I really wouldn't worry about what other information the computer shows for the file
 
I noticed that for Windows File Explorer to display Date/times of a recorded video correctly in a given Time Zone, both the camera doing the recording and the PC reading the file need to be operated in the same Time Zone. To do otherwise just adds to the Date/time confusion. Only the Date/time embedded in the filename of the recorded video stays true regardless of the PC time zone and it will display as the Date/time of the video start in whatever Time Zone the camera was set to when the recording was made.
 
DashcamDPR said:
I think what matters for purposes of an incident, or legal proof, is that the date/time stamp on the footage itself is correct, if the file name correctly corresponds with the timestamp (usually the start time of each file) I really wouldn't worry about what other information the computer shows for the file
Click to expand...
agree, this is all you really need to see:

pic1-crop.webp


🙂
 
DashcamDPR said:
I think what matters for purposes of an incident, or legal proof, is that the date/time stamp on the footage itself is correct, if the file name correctly corresponds with the timestamp (usually the start time of each file) I really wouldn't worry about what other information the computer shows for the file
Click to expand...

I agree! After the weekend I will show out screenshots from different OS (I dont't like MS and Windows !!! Only do not tell anyone! 😉 )
It's just inconvenient to find the file you need
 
The file name contains the time and date, easy enough to see, if it's a recording from my own car I just use thumbnail view anyway, very easy to know where you are in 99% of journeys just from the first frame of each file
 
Minuel said:
It's just inconvenient to find the file you need
Click to expand...

Press the emergency button on the dashcam 🙂 save the required file into a separate folder
 
Found this thread 7 years later and surprised it persists. My new Vantrue N4 records file names with timezone adjustments correctly (because the recordings are for events in a particular timesone) but also marks the file creation time by applying the the timezone adjuistment. This is not good behavior. File times in metadata should always be recorded using UTC as a reference, without timezone adjustment. As a result of this bug, all operating systems/applications which properly apply an offset before formatting a time for display (so that it can be presented from the perspective of the user in their current timezone) will offset the time from the recording local zone rather than the proper fixed reference of UTC. For a typical user this means the same offset is applied twice, so folks in NJ (for example) will see times that are off by 5 hours in winter, 4 in summer. Brits won't notices a problem during the winter.

We can all work around it but it is clearly wrong and reflects very badly on the manufacturer after so many years.
 
I have found that all of my Sony cameras also have this bug. That is a Sony RX-100, A7RII, and an A7CR. It is appalling how long this bug has persisted, and on how many cameras.
It's a bug, it should be fixed. I don't care how easy it is to work around. Camera manufacturers should be embarrassed by this bug.
 
DAP said:
I have found that all of my Sony cameras also have this bug. That is a Sony RX-100, A7RII, and an A7CR. It is appalling how long this bug has persisted, and on how many cameras.
It's a bug, it should be fixed. I don't care how easy it is to work around. Camera manufacturers should be embarrassed by this bug.
Click to expand...
Out of curiosity what os are you using?
 
You must log in or register to reply here.
Back
Top