CONVERT Modified dates, December 25th 2020 11:15:23 PM AND 12/25/2020 11:15:23 PM, to 2020-12-26T07:15:23Z AND 2020-12-25 23:15:23-08:00, to UTC

Can someone provide a regex for me on how to convert dates to UTC because I am trying to create 2 separate format value (format string) ACTIONS? For example, from the image below, that is RED-BOXED highlighted, I would like to convert the modified date, December 25th 2020 11:15:23 PM AND 12/25/2020 11:15:23 PM, to 2020-12-26T07:15:23Z AND 2020-12-25 23:15:23-08:00.

Moreover, I don't recall which mp3tag forum I found this regex for the Action, $regexp(%_file_mod_datetime%,'(\d\d)/(\d\d)/(\d\d\d\d) (.*)',$3-$1-$2T$4), but it converts the modified date to 12/25/2020 11:15:23 PM instead of what I want: 2020-12-26T07:15:23Z AND 2020-12-25 23:15:23-08:00. Basically, what I am seeking are two different regex, one for converting to 2020-12-26T07:15:23Z and the other to 2020-12-25 23:15:23-08:00. Thank you.

AFAIK the file time properties for creation, modification and access are managed by the OS and the OS and its local settings also determine the display format.
Was it this thread:

fyi, if a regex is valid, but no matches are found, the original string is returned.
The regex you provided will fail if the day or month has only 1 digit.

I can't figure out the relationship between the Modified date shown in File Explorer and your desired formats.
Are December 25th 2020 11:15:23 PM and 12/25/2020 11:15:23 PM equivalent to 2020-12-26T07:15:23Z and 2020-12-25 23:15:23-08:00?
If so, you will have to be more specific about how to convert from one to the other.
It seems as if time zones are involved, but you give no information about how that is known.

I just got an epiphany: perhaps the OP looks for a way to sort by these various date formats - in MP3tag.
The idea here would be:
there is a property variable %_file_create_datetime_raw% - this returns a plain number (seconds since x) and can be used for sorting when entered in the column-definition at "Sort by". Like that you become independent from the system settings whether you get a long or short date displayed.

1 Like

I believe that wneclass2018 wants to tag MKV files with a date in a specified format. Run a TOOL Command, based on selection, in a SINGLE WINDOW

And I agree that %_file_create_datetime_raw% might be better suited for that purpose.
I'll wait and see if he returns with more information.

Good afternoon, sir. Thanks for replying. As for the action that you provided for me, I did as instructed and also added a "Remove fields" below:


The question you asked, "Are December 25th 2020 11:15:23 PM and 12/25/2020 11:15:23 PM equivalent to 2020-12-26T07:15:23Z and 2020-12-25 23:15:23-08:00?," is yes, they are the equivalent: 2020-12-26T07:15:23Z and 2020-12-25 23:15:23-08:00 are the UTC timestamps of December 25th 2020 11:15:23 PM and 12/25/2020 11:15:23 PM. Moreover, as you can see, for December 25th 2020 11:15:23 PM, the UTC timestamp added 8 hours, changing the day from the 25th to the 26th, 2020-12-26T07:15:23Z, compared to 2020-12-25 23:15:23-08:00, that will add 8 hours and resemble 2020-12-26T07:15:23Z once I run it via mkvpropedit.exe.

Thus, my timezone is Pacific Standard Time (7 hrs UTC and 8 hrs UTC accounting for Daylight savings), and when I used mkvmerge.exe to remux the file on December 25th 2020 11:15:23 PM, on MediaInfo.exe, under Encoded Date, it lists the UTC time as 2020-12-26 07:15:23, adding 8 hrs into it to account for daylight savings. Moreover, from the Windows File Properties image, on my first post, using Gillmeister Rename Expert, there's a feature to read Video encoded date metadata, allowing me to set the Modified timestamp to December 25th 2020 11:15:23 PM, PRIOR to the UTC date for the MKV file, which you can see in the highlighted RED-BOXED image from the first post. I am not sure if it's possible to have regexp that accounts for UTC time such as adding a "-08:00" or "-07:00", as seen in ExifTool, at the end of the timestamp. Or is there a regexp that can just convert directly to UTC 2020-12-26T07:15:23Z?

No, there isn't.
Yet, what is the point to do all these transformations - if you can only read the date?
And as soon as you used another program to modify the date, then it is stored as file property which can be read by MP3tag either as raw data or as formatted data. The formatting depends on your system settings.

Oh no, the point of it all, as @ryerman has helped me in the past, is to restore the encoded date using mkvpropedit, in which he provided an MTE for me to accomplish this task since mkvmerge lacks on option to retain the original encoded date. Nevertheless, for example, when I used MetaX to add Metadata into mkv files, it literally removed the encoded date. For me, the encoded date informs me on how old the file is, which is why I wanted or hoped for a regexp that could fulfill that request based upon UTC & Windows File Properties. Another example would be that MP3Tag, in my opinion should be changed to AllPurposeTag because this software is truly remarkable, allows me to include a "CREATION_TIME" or "%creation_time%" field, which, when you use Mediainfo.exe, writes your timestamp of choice (i.e. 2019-12-25T17:18:52Z) into the Encoded Date field, as seen below. Additionally, this also applies to IDM, when I enable the Set file creation date as provided by the server. Nonetheless, thank you, and I appreciate your input, and, apologies, it seems that I am a stickler for having the exact encoded date of a video file. The IDM method is what I use for majority of MP4 files, alongside ExifTool, via the External Tools option.

And as for @ryerman, thank you, sir. I will modify what you sent me by creating two separate actions to account for Daylight savings by using a replace option, replacing "Z" into "-08:00" or "-07:00" in which mkvpropedit.exe, ffmpeg.exe to mux to mp4, and ExifTool to append the date to an existing mp4/m4a file should be able to read, respectively.

1 Like

For all this book keeping - what about the field RELEASETIME?
This is even a tag field that gets evaluated by some players - and it does not get modified by the OS. So, as soon as you get a file, it could be an idea to write that date into RELEASETIME.

I makes absolutely no sense to me to manupulate the date that is managed by the OS to keep personal informations which should be included in the metafata.

1 Like

ENCODINGTIME, RELEASETIME, and CREATION_TIME are very different because, on MediaInfo.exe, CREATION_TIME, for mkv files, is shown as "Encoded date" while ENCODINGTIME and RELEASETIME are shown under their own fields via MediaInfo. Furthermore, CREATION_TIME, when used upon mp4 files, using ffmpeg's "-map_metadata 0", will push the entry date in the CREATION_TIME field from Mp3tag, and will reflect Windows File Properties DETAILS tab "Media Created" tag. You may see it as a waste of time, but it's actually essential. For example, I am in the medical field: we read studies to formulate new plans on how to better treat and assess our patients. If you go onto PubMed, they have a filter regarding "Dates" on the articles, establishing how old the articles or scientific journals are. Asthma guidelines were changed in 2019, and, just like the encoded date, if you don't have that timestamp, you may think the videos (articles) are new, after being remuxed by mkvmerge, which doesn't give you the option of preserving the original encoded date. Regarding Gillmeister Rename Expert, from the two images below, you can see how pivotal the CREATION_TIME (aka Encoded Date) plays a role in assigning a TimeStamp to reflect on Windows File Properties GENERAL tab. Moreover, looking back at the "Encoded date" image in my previous response, I implemented the CREATION_TIME as 2019-12-25T17:18:52Z, and since I remuxed it with mkvmerge, under Encoded date, it displayed it as 2022-01-16 22:13:16 / 2019-12-25T17:18:52Z. Afterwards, I use mkvpropedit, via Mp3Tag Tools, to writing the MP3Tag CREATION_TIME entry into mkvpropedit, producing an Encoded date as 2019-12-25 17:18:52 / 2019-12-25T17:18:52Z, and then I ran Gillmeister rename expert, as you can see from the images below.

I know that I may sound like a broken record, but I like my videos to be organized regarding when it was encoded, and @ryerman, with his VBS Script, helped me return the original Encoded date using mkvpropedit via the Mp3tag's EXPORT options. Thus, I am aware that @ryerman stated that I shouldn't post anything, under Support, that's not specific to Mp3tag software, but my request was Mp3tag-related: regular expression to convert between timezones. Nonetheless, thank you all for everything, especially @ryerman: I truly appreciate the patience and how you assisted me on all my request.

P.S. Sorry, I wouldn't be wasting any of your time if MKVToolNix (mkvmerge.exe; mkvpropedit.exe) had an option to preserve the original encoded date, or if I could create a batch script that would easily allow me to write ample differing CREATION_TIME via mkvpropedit GUI.

1 Like

Regarding the .mta file that you sent me, it looks like there's an error regarding the time, from the HH in HH:mm:ss from 12:00:00 AM (00:00:00) and anything before 12:00:00 PM. For starters, for 12:00:00 AM, the .mta writes it as "24:00:00", and any time prior to noon, such as 07:00:00 is written as 19:00:00, which is 7pm.

Sorry, I goofed. :frowning_with_open_mouth:
I was not careful enough when analyzing the time conversion.
Also, there was a gross error in the script.

I will try to re-write the script to give correct results.

Here are my assumptions:
12:00:00 PM is noon.
12:00:00 AM is midnight and can be displayed as either 00:00:00 or 24:00:00 with a 24-hour clock.
12:00:00 AM will convert to 00:00:00
There may be some ambiguity about whether 00:00:00 is the beginning or end of whatever day is specified.

If you prefer to convert 12:00:00 AM to 24:00:00, tell me.

Thanks for responding. I prefer the military time as I believe that's the only format UTC runs by. Thus, I changed the 24:00:00 into 00:00:00 using a replace function such as, excluding the quotes, "T24:" to "T00:". The main problem was that, for example, 07:00:00, 08:00:00, 09:00:00, and any time before 12:00:00 will come up as 19:00:00, 20:00:00, 21:00:00, which is an addition of 12 hours: 07:00:00 (aka 7 am) vs. 19:00:00 (7pm). Basically, let's say, according to Windows File Properties, the Modified time for a file read as January 11th 2022 1:23:22 AM (aka 2022-01-11 01:23:22), the .mta file you provided, once the action is performed, will write it as incorrect time 2022-01-11T13:23:22Z instead of the correct value 2022-01-11T01:23:22Z.

You might think that after 60+ years on the planet I would know how to tell time, but apparently I needed another lesson. :slightly_smiling_face:
Hopefully, the attached script will be satisfactory.
CORRECTED-Convert Modified date for MKV files.mta (1.2 KB)

I know I sound like a broken record, but THANK YOU, THANK YOU, THANK YOU. I really appreciate it because it worked. Thus, 60+ years of coding, and you have yet to lose your touch, sir.

1 Like