[2020] Convert Nsf To Pst Torrent
Mazie Wingeier
Ok, so the source (FM2022) needs to save the content back into either FM2020 or MIF format. Nothing you can do from the FM2020 end of things. No reason why putting the FM2022 trial on a completely separate machine wouldn't work either for the purposes of back-saving.
Thank you Bjorn. Note that ConvertDocs can only "push" documents down to an older version; it can't "pull" them down from an newer version. So, for example, you would have to use ConvertDocs with FrameMaker 2022 to save them down to any earlier version. You can't use ConvertDocs with FrameMaker 2020 in order to convert FrameMaker 2022 files to 2020.
All that's needed for that is a naive machine, perhaps just a virtual machine, for the temporary installation.
For a small number of files, getting someone else to help with the save-back is another path.
It's easily possible that content security would prevent that, but in an enterprise setting like that, I'd push back, through management if necessary, to get the prior document stewards to provide the MIF. My dept. used to routinely generate MIFs, largely because it was hard to predict what FM version the outside translators would have.
One problem is that strptime will struggle with the way the offset (GMT 4.30) is formatted at the end. Since the term 'GMT' is all you should need to retrieve the timezone, I suggest stripping the rest out using regex - if the timezone matters to you.
After creating the datetime object from the string, I have shown both string formatting and strftime to convert the datetime to required format. As you can see the strftime returns a zero padded month which is not required for your case.
Hi. I'm using 2002, but have been sent a current .dwg file which Wordpad identifies as AC1032 so Acad 18/19/20. Needless to say 2002 won't read it. I have loaded Trueview but when I try to convert the resulting file is still incompatible. I note that Wordpad identifies the converted file as AC1018 so Acad 04/05/06 not 00 which is what was selected in Trueview. I have downloaded several times both current and older versions of Trueview with the same results. I know I could go back and ask for the file to be sent in the older format but why won't Trueview work?
Are you able to open the new file in true view? Some newer files will have objects @RobDraw mentioned that will need to be exploded. Also, some are vba enabled objects that will crash Autocad or just not allow you to open the file if you do not have the vba installed. To get around these issues the file needs to have aec objects exploded.
Thank you for your response. This is not working since my data type is DateTime but the screenshot you shared has the data type V_Wstring. Is there any other way to convert this format, please assist.
@troy_mech , that will not be possible as the default date/time format in alteryx is yyyy-mm-dd and we are converting it to a custom format dd/mm/yyyy so that has to be in string format in order to reflect the result.
Paul: This is like a formula posted by Joe Mako elsewhere, which takes the DateTime and just converts it into a String that doesn't show the time--that's not a change in datatype from DateTime to Date. The problem is that Alteryx developers are not listening to users; we need one tool where we can specify basic date handling functions--it's not rocket science, just lack of focus.
You can manage the data type conversion in a formula by creating a new field that is a date and setting it equal to the field having the datetime value. Same as using a SELECT tool but cleaner; especially since you can stack the formulas into the same tool.
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.
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.
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.
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.
You might think that after 60+ years on the planet I would know how to tell time, but apparently I needed another lesson.
Hopefully, the attached script will be satisfactory.
CORRECTED-Convert Modified date for MKV files.mta (1.2 KB)