I'm really not trying to be lazy, and this otherwise may just boil down to my lack of familiarity with some potential string format functions or methods that might be available in jscript to make easy work of this, or just using some regex thingie in the srcipt - but:
The date format that is returned in the Item.modify property is in a format of:
Thu Jul 1 04:00:00 EDT 1999
...which I can't reuse "as-is" in order to set the modifieddate of another item... so wondering if:
a. GPSoft might consider returning the date string in a format that can easily be re-used by other Opus commands (i.e. setattr like simple YYYYMMDD or YYYY-MM-DD)?
b. Is anyone familiar with some use of jscript Date() methods to convert the date string above into something like a YYYY-MM-DD HH:MM:SS format?
On a related topic, I'm also curious if anyone can offer up a reason why some folders that I just set modifieddate on using setattr report EDT and some EST. I set the dates on these folders within minutes of each other, and yet from a test script I get a mixture of DST strings like:
Source Folder ModifiedDate: Fri Feb 3 05:00:00 EST 1995
Dest Folder: D:\my\My Media\My Music~fix_dates2\Dark Tranquillity - 1995 - Of Chaos And Eternal Night :: exists!
Opus doesn't return the date in any particular format, it's returned as a variant of type VT_DATE. I'm not familiar enough with JScript to know but presumably it has something like VBScript's DatePart() function that would let you extract the various parts of the date field and build a string in the desired format.
Thanks alot Jon, that helped. Telling me you're just returning a variant of a system defined date type - lo and behold, we can just use that string when casting a new date object and can use most of the date objects methods like:
[code]@language jscript
function OnClick(ClickData)
{
var objEnum = new Enumerator(ClickData.func.sourcetab.selected);
DOpus.OutputString("\nFunction Begin...");
if (!objEnum.atEnd())
{
while (!objEnum.atEnd())
{
var objDate = new Date(objEnum.item().modify);
strSrcItemModify = toISOString(objDate);
function toISOString(date)
{
var m = 1+date.getMonth();
var d = date.getDate();
return date.getFullYear()+"-"+(m<10?'0'+m:m)+"-"+(d<10?'0'+d:d);
}[/code]
...for some reason none of the to like methods associated with the javascript Date object work on my system. I couldn't get a concise answer when searching why this is, but found a workaround on google code. Maybe a jscript vs javascript version thing .
Actually, something DOES seem off here with the Item.modify value returned, or else I'm the one that's not understanding something properly...
From the following selected folders that show this info in Opus:
Dark Tranquillity - 1993 - Skydancer 7/1/1999 12:00 AM
Dark Tranquillity - 1995 - Of Chaos And Eternal Night 2/3/1995 12:00 AM
...the Item.modify values returned are:
Source Item: Dark Tranquillity - 1995 - Of Chaos And Eternal Night
Item.modify: Fri Feb 3 05:00:00 EST 1995[/code]
...the first excerpt is just some print folder output from the folder I'm running something like the sample script above in. As you can see, the time being displayed by Opus is 12:00 AM. And that should in fact be 12:00 AM already at whatever my system timezone (whether EDT or EST, lets go with what you had thought about why whichever one is cast) is set to.
Why then does it seem that the TIME part is being FURTHER adjusted for timezone in the value returned in Item.modify? The value is being treated as though the TIME of my folders are in GMT/UTC or something and need to be adjusted. Which, even if true - the DATE part of the value isn't even being adjusted accordingly, even if the real modified time was in fact GMT/UTC.
Timestamps are returned as UTC, since this is how the file system stores them, but that's probably not that useful in reality so we'll change it in the next beta to return local times (and add additional properties for UTC timestamps in case there is a use for them).
Thanks for looking at it... and not to be a pest or contrary, but if the time is being returned as UTC, why then does it have an EST or EDT string as part of the value rather than UTC?
Again, we just return a variant VT_DATE, how it's displayed is up to the scripting language (which is obviously making assumptions about the time zone).
Hmmm, I'm curious what will be returned if you make the change to return local time... as it is Jscript seems to be seriously confused by how this is implemented. Checking dates and times in standalone jscripts seems fine on my system when getting to them using filesystem objects.
Yet through this interface with Opus, somethigns getting confused, but not the case for VBScript.
id anyone else can verify if they seem the same on their system, maybe it might point to some system thing I can change or fix. I'd really like to use Jscripts for most of my needs...
Here are two script buttons for anyone willing to test if the output is the same between both JS and VB on their systems - OR - if like on my system the Jscript interface is flat out WRONG and the VBscript interface is correct:
Jscript button:
<?xml version="1.0"?>
<button backcol="none" display="both" label_pos="right" separate="yes" textcol="none">
<label>JS Test Modify</label>
<icon1>#setattr</icon1>
<function type="script">
<instruction>@language jscript</instruction>
<instruction />
<instruction>function OnClick(ClickData)</instruction>
<instruction>{</instruction>
<instruction> var objEnum = new Enumerator(ClickData.func.sourcetab.selected);</instruction>
<instruction> DOpus.OutputString("\nJS Function Begin...");</instruction>
<instruction> if (!objEnum.atEnd())</instruction>
<instruction> {</instruction>
<instruction> while (!objEnum.atEnd())</instruction>
<instruction> {</instruction>
<instruction> var objDate = new Date(objEnum.item().modify);</instruction>
<instruction />
<instruction> DOpus.OutputString("\nSource Item: " + objEnum.item().name);</instruction>
<instruction> DOpus.OutputString("Item.modify: " + objEnum.item().modify);</instruction>
<instruction />
<instruction> objEnum.moveNext();</instruction>
<instruction> }</instruction>
<instruction> }</instruction>
<instruction> DOpus.OutputString("\nJS Function End...");</instruction>
<instruction> delete objEnum;</instruction>
<instruction>}</instruction>
</function>
</button> VB button:
<?xml version="1.0"?>
<button backcol="none" display="both" label_pos="right" textcol="none">
<label>VB Modify Test</label>
<icon1>#setattr</icon1>
<function type="script">
<instruction>@language vbscript</instruction>
<instruction>option explicit</instruction>
<instruction />
<instruction>Function OnClick(ByRef ClickData)</instruction>
<instruction />
<instruction> DOpus.OutputString(VBCRLF & "VB Function Begin...")</instruction>
<instruction> Dim x</instruction>
<instruction> Dim objSelectedItems</instruction>
<instruction> Set objSelectedItems = ClickData.func.sourcetab.selected</instruction>
<instruction> For Each x in (ClickData.func.sourcetab.selected)</instruction>
<instruction> DOpus.OutputString(VBCRLF & "Source Item: " & x.name)</instruction>
<instruction> DOpus.OutputString("Item.modify: " & x.modify)</instruction>
<instruction> Next</instruction>
<instruction> DOpus.OutputString(VBCRLF & "VB Function End...")</instruction>
<instruction />
<instruction>End Function</instruction>
</function>
</button>
Source Item: Savatage - 1984 - The Dungeons Are Calling (1994)
Item.modify: 8/25/2013 1:00:00 AM
VB Function End...[/code]
The code is just passing through the Item.modify value unaltered in each case. I'm guessing that while the times are shown with the same date and time values (correct time and date adjustments being made for EDT == UTC-4, but oddly different formatting between each language though???) that the VBscript output is intended to be implied as being in UTC with the lack of an explicit timezone string... whereas the Jscript output is plain wrong by including the EDT timezone string.
Can anyone else see if you get the same incorrect info on their systems...? Wondering if it's "just me" or if the Jscript interface is wrong across the board.
Is there anything there that can't be explained by JScript assuming the times given to it are in the local timezone, and sticking "EDT" or "EST" on the end of a string because of that assumption, and nothing more?
VBScript's lack of a timezone should not be taken to imply the time is in UTC (even if it is in this case). It just means there is no timezone. VBScript is being "more correct" there, because no timezone was specified and JScript is wrong to assume one was. But the actual date/time values shown by both versions of the script are identical, aside from the bogus timezone string JScript is displaying.
Note that the VT_DATE format does not have any timezone information attached to it at all. VT_DATE is just a number ("a floating point value, counting days since midnight 30 December 1899, with hours and minutes are represented as fractional days").
I agree with what you're saying, and I did understand Jon pointing out how the data is being passed. I was mainly concerned it was something system specific (just me), and was really just wondering if other people see the same incorrect assumption by Jscript on their systems. I'm not just trying to spin my wheels for no good reason or because I have too much time on my hands . Obviously, the result is that we get incorrect data returned. I'm not "blaming" Opus... But I'm preoccupied by it because when I was trying to find out why the JavaScript Date objects' toString-like methods were throwing a 'not supported' error at me, I didn't find a concise answer as to why; but did see that certain Jscript versions and web browser implementations apparently had varying levels of support for those methods... This makes me wonder if different Jscript versions might also have different assumptions about timezone when being passed a VT_DATE value.
In which case:
If it were just a problem on my system due to some system specific setting or Jscript version thing, then any change you guys might make like Jon mentioned (having an explicit additional property for UTC vs changing the current property to pass through local timezone, which I take to be an accommodation of this apparent Jscript bug), then your attempt to patch it might still result in some people getting incorrect info and having to massage it themselves in each script where this info is needed.
If it is shown to be incorrect for everyone (not just me) then I'm happy to just use whatever new 'localized' return you guys may switch to and call it a day...
Also kind of weird that this seems to work as expected in a Script window:
var myDate = new Date();
DOpus.OutputString(myDate.toString());
DOpus.OutputString(myDate.toUTCString());
...is Jscript just crazy depending where the Date object is coming from? Lol... interested in seeing how it plays out.
A variable containing a variant of type VT_DATE is presumably not the same as a JScript Date object. You can probably create a Date object and feed the VT_DATE value into it in some way.
.
. Obviously, the result is that we get incorrect data returned. I'm not "blaming" Opus... But I'm preoccupied by it because when I was trying to find out why the JavaScript Date objects'