WSH VBS question

[Dr J R Stockton]

Within Windows Scripting Host running VBScript, e.g. in '
Prompt>CScript //nologo FILE.VBS ',
is it possible, given a general CDate variable, to
determine the offset from GMT/UTC of the date/time
represented by the value of the variable, or equivalent
information, and if so how,

(a) Using features of VBScript itself,
(b) Otherwise, using some API or system call,
without invoking JScript?

--
(c) John Stockton, near London, UK. Using Google Groups. |
Mail: J.R.""""""""@physics.org - or as Reply-To, if any. |

[JJ]

On Thu, 8 Feb 2018 13:30:07 -0800 (PST), Dr J R Stockton wrote:
> Within Windows Scripting Host running VBScript, e.g. in '
> Prompt>CScript //nologo FILE.VBS ',
> is it possible, given a general CDate variable, to
> determine the offset from GMT/UTC of the date/time
> represented by the value of the variable, or equivalent
> information, and if so how,
>
> (a) Using features of VBScript itself,
> (b) Otherwise, using some API or system call,
> without invoking JScript?

Since VB date represent the local time, and IEEE date represent the UTC
time, the time difference will give you the time zone of your system. So,
manually decode the IEEE date then compare the result with the one converted
from CDate.

[Dr J R Stockton]

So how does one get the "IEEE date", whatever that term is supposed to mean, corresponding to the aforementioned CDate variable, preferably using just VBScript, and in what form does one get it?

[JJ]

On Fri, 9 Feb 2018 05:20:01 -0800 (PST), Dr J R Stockton wrote:
> On Friday, February 9, 2018 at 11:36:13 AM UTC, JJ wrote:
>> On Thu, 8 Feb 2018 13:30:07 -0800 (PST), Dr J R Stockton wrote:
>>> Within Windows Scripting Host running VBScript, e.g. in '
>>> Prompt>CScript //nologo FILE.VBS ',
>>> is it possible, given a general CDate variable, to
>>> determine the offset from GMT/UTC of the date/time
>>> represented by the value of the variable, or equivalent
>>> information, and if so how,
>>>
>>> (a) Using features of VBScript itself,
>>> (b) Otherwise, using some API or system call,
>>> without invoking JScript?
>>
>> Since VB date represent the local time, and IEEE date represent the UTC
>> time, the time difference will give you the time zone of your system. So,
>> manually decode the IEEE date then compare the result with the one converted
>> from CDate.
>
> So how does one get the "IEEE date", whatever that term is supposed to mean, corresponding to the aforementioned CDate variable, preferably using just VBScript, and in what form does one get it?

IEEE date format (AFAIK, same as POSIX time format) is the number of
milliseconds since January 1st 1970 UTC. IIRC, the official storage format
is a 64-bit integer but 64-bit floating point can be used to contain it too.

You can use the MOD operator and `\` (integer divide) to extract the
millisecond (of a second), second, minute, and hour.

millisecond = SourceDate mod 1000
remain = SourceDate \ 1000
second = remain mod 60
remain = remain \ 60
minute = remain mod 60
remain = remain \ 60
hour = remain mod 24
remain = remain \ 24

It'll get more complicated once you start extracting the day (of month) and
greater time units because leap year should be taken into account. I'm not
versed on calculating these, so I'd suggest googling for it. Or maybe
someone here or in other programming newsgroups, knows.

[Dr J R Stockton]

On Friday, February 9, 2018 at 9:41:45 PM UTC, JJ wrote:
> On Fri, 9 Feb 2018 05:20:01 -0800 (PST), Dr J R Stockton wrote:
> > On Friday, February 9, 2018 at 11:36:13 AM UTC, JJ wrote:
> >> On Thu, 8 Feb 2018 13:30:07 -0800 (PST), Dr J R Stockton wrote:
> >>> Within Windows Scripting Host running VBScript, e.g. in '
> >>> Prompt>CScript //nologo FILE.VBS ',
> >>> is it possible, given a general CDate variable, to
> >>> determine the offset from GMT/UTC of the date/time
> >>> represented by the value of the variable, or equivalent
> >>> information, and if so how,
> >>>
> >>> (a) Using features of VBScript itself,
> >>> (b) Otherwise, using some API or system call,
> >>> without invoking JScript?
> >>
> >> Since VB date represent the local time, and IEEE date represent the UTC
> >> time, the time difference will give you the time zone of your system. So,
> >> manually decode the IEEE date then compare the result with the one converted
> >> from CDate.

A single time difference or offset is not necessarily enough to determine Time Zone, which represents the Standard Time (= Winter Time) offset from UTC, in spite of the fact that Microsoft think differently.

> > So how does one get the "IEEE date", whatever that term is supposed to mean, corresponding to the aforementioned CDate variable, preferably using just VBScript, and in what form does one get it?
>
> IEEE date format (AFAIK, same as POSIX time format) is the number of
> milliseconds since January 1st 1970 UTC. IIRC, the official storage format
> is a 64-bit integer but 64-bit floating point can be used to contain it too.

That is a way, used in some languages and operating systems, of storing an integer number of seconds in an IEEE-754 64-bit variable. Google shows a mere 10 references to "IEEE date format"; about half of them refer to your format and about half to something matching or like the commonest of the ISO 8601 date formats. If the IEEE really had defined a sensible date format (other than by reference to ISO), I would have learned of it long ago.

My question to you was 'how does one get the "IEEE date"' (which you cited); I don't need to be told how to deal with it - provided that it is indeed independent of locality. And I want to get it by using VBScript.

> You can use the MOD operator and `\` (integer divide) to extract the
> millisecond (of a second), second, minute, and hour.
>
> millisecond = SourceDate mod 1000
> remain = SourceDate \ 1000
> second = remain mod 60
> remain = remain \ 60
> minute = remain mod 60
> remain = remain \ 60
> hour = remain mod 24
> remain = remain \ 24
>
> It'll get more complicated once you start extracting the day (of month) and
> greater time units because leap year should be taken into account. I'm not
> versed on calculating these, so I'd suggest googling for it. Or maybe
> someone here or in other programming newsgroups, knows.

Why search for it? The Leap Year Rules and the month lengths should all have been taught in schools (they, and other stuff, were printed on the back cover of school exercise books in my day) - and they are not needed, since I am only interested in the time offset (and am prepared to disregard those who live 12 hours or more away from GMT).

See, for example,
<http://web.archive.org/web/20150907215912/http://www.merlyn.demon.co.uk/zeller-c.htm>.

[JJ]

On Sat, 10 Feb 2018 02:47:42 -0800 (PST), Dr J R Stockton wrote:
>
> My question to you was 'how does one get the "IEEE date"' (which you
> cited); I don't need to be told how to deal with it - provided that it is
> indeed independent of locality. And I want to get it by using VBScript.

That's entirely depend on your source of data. The CDate function is for
handling IEEE date value which isn't compatible with VB. VB's date format
itself is not IEEE date format. VB also has no built in function for
creating IEEE dates.

[Dr J R Stockton]

Have you anything useful to say, such as might answer my questions?

[JJ]

On Sun, 11 Feb 2018 02:57:21 -0800 (PST), Dr J R Stockton wrote:
> On Saturday, February 10, 2018 at 11:56:05 AM UTC, JJ wrote:
>> On Sat, 10 Feb 2018 02:47:42 -0800 (PST), Dr J R Stockton wrote:
>>>
>>> My question to you was 'how does one get the "IEEE date"' (which you
>>> cited); I don't need to be told how to deal with it - provided that it is
>>> indeed independent of locality. And I want to get it by using VBScript.
>>
>> That's entirely depend on your source of data. The CDate function is for
>> handling IEEE date value which isn't compatible with VB. VB's date format
>> itself is not IEEE date format. VB also has no built in function for
>> creating IEEE dates.
>
> Have you anything useful to say, such as might answer my questions?

OK, then give me an example of the date you want to work with.

[Dr J R Stockton]

Ideally, UTC noon on all dates within the CDate range, which as I recall includes the years 0100 to 9999. All dates within 2018 to 2022 will at present suffice, as would CDate(43100) to CDate(43100+1830).

This must be done with VBScript called by WSH in a batch file. Alternatively, I could use local noon for those dated and somehow find the corresponding UTC Date/Time or time_t in any reasonable format (or in FFF).

[David Solimano]

On Thu, 8 Feb 2018 13:30:07 -0800 (PST), Dr J R Stockton
<J.R.St...@physics.org> wrote:

>Within Windows Scripting Host running VBScript, e.g. in '
> Prompt>CScript //nologo FILE.VBS ',
>is it possible, given a general CDate variable, to
>determine the offset from GMT/UTC of the date/time
>represented by the value of the variable, or equivalent
>information, and if so how,
>
>(a) Using features of VBScript itself,
>(b) Otherwise, using some API or system call,
>without invoking JScript?

Would something like this work

https://stackoverflow.com/a/22842128/58074

Set dateTime = CreateObject("WbemScripting.SWbemDateTime")
dateTime.SetVarDate (now())
wscript.echo "Local Time: " & dateTime
wscript.echo "UTC Time: " & dateTime.GetVarDate (false)

Using your date instead of now()?

--
David Solimano
da...@solimano.org

[Dr J R Stockton]

On Tuesday, February 13, 2018 at 3:21:41 AM UTC, David Solimano wrote:

> On Thu, 8 Feb 2018 13:30:07 -0800 (PST), Dr J R Stockton wrote:
>
> >Within Windows Scripting Host running VBScript, e.g. in '
> > Prompt>CScript //nologo FILE.VBS ',
> >is it possible, given a general CDate variable, to
> >determine the offset from GMT/UTC of the date/time
> >represented by the value of the variable, or equivalent
> >information, and if so how,
> >
> >(a) Using features of VBScript itself,
> >(b) Otherwise, using some API or system call,
> >without invoking JScript?
>
> Would something like this work
>
> https://stackoverflow.com/a/22842128/58074
>
> Set dateTime = CreateObject("WbemScripting.SWbemDateTime")
> dateTime.SetVarDate (now())
> wscript.echo "Local Time: " & dateTime
> wscript.echo "UTC Time: " & dateTime.GetVarDate (false)
>
> Using your date instead of now()?

YES!

wscript.echo "LCT Time: " & dateTime.GetVarDate (true)

gives Local Civil Time in the same format as with (false), which is nice, and the format is my preferred one (ISO 8601, YYYY-MM-DD) which I have set in Windows.

But .GetVarDate() is not needed, except as a confidence booster, because

> wscript.echo "Local Time: " & dateTime

gives, here in the UK, such as

Local Time: 20180807120000.000000+060

and I only need the last four characters for the offset.


The background is that, in all my browsers, JavaScript correctly uses the UK/EU rules for Summer Time, but I have observed that at the "MS-DOS" command line cscript filename.JS uses the US DST rules, which is an objectionable bug. Therefore, I began to wonder what the situation might be with cscript filename.VBS .

VBScript proper uses only local date/time with only 24-hour days, so cannot show the bug unaided. Using WbemScripting, which I do not know enough about, the absence of a corresponding bug is easily shown.

Thanks.

[Dr J R Stockton]

On Tuesday, February 13, 2018 at 10:34:45 AM UTC, Dr J R Stockton wrote:
> On Tuesday, February 13, 2018 at 3:21:41 AM UTC, David Solimano wrote:

> > Would something like this work
> >
> > https://stackoverflow.com/a/22842128/58074
> >
> > Set dateTime = CreateObject("WbemScripting.SWbemDateTime")
> > dateTime.SetVarDate (now())
> > wscript.echo "Local Time: " & dateTime
> > wscript.echo "UTC Time: " & dateTime.GetVarDate (false)
> >
> > Using your date instead of now()?
>
> YES!

> The background is that, in all my browsers, JavaScript correctly uses the
> UK/EU rules for Summer Time, but I have observed that at the "MS-DOS"
> command line cscript filename.JS uses the US DST rules, which is an
> objectionable bug. Therefore, I began to wonder what the situation might be
> with cscript filename.VBS .
>
> VBScript proper uses only local date/time with only 24-hour days, so cannot
> show the bug unaided. Using WbemScripting, which I do not know enough
> about, the absence of a corresponding bug is easily shown.

=============


But there is a non-corresponding bug. Using the code cited above in a loop. I stepped through several years of Local Noon, finding changes on the correct dates. The results obtained by stepping minute-by-minute through local time were confusing, since each year an hour of local time is, for much of the world, omitted, and an hour is duplicated. So I changed to using the next bit of code on the cited page, to step minute-by-minute through three years of GMT.

That showed (in the UK) that the autumn change is one hour late in Win XP sp3 and in current Win 7, but is correct in Win 10.

Apparently there are other ways of getting the offset of local time from
UTC; I don't know what results they might give.


Executable Code :

WScript.echo ""
WScript.echo "(c) J R Stockton >= 2018-02-15"
WScript.echo "Use : Prompt> cscript //nologo TIME-BUG.VBS"

'' See https://stackoverflow.com/questions/15887700/utc-time-assignment-in-vbscript/22842128#22842128 (unwrapped)

WScript.echo ""

Set DT = CreateObject("WbemScripting.SWbemDateTime")

Dim XS, XOff

Sub SubRtn2(K)
DT.SetVarDate CDate(D0+K), false '' Where Arg 1 is the UTC date
UTC = CDate(DT.GetVarDate(false))
DoW = " " & WeekdayName(Weekday(UTC))
LCT = CDate(DT.GetVarDate(true))
Off = CInt((CDate(LCT) - CDate(UTC)) * 1440) '' minutes
S = " UTC = " & UTC & DoW & ", LCT = " & LCT & ", Offset = " & Off
if ((K<>0) and (XOff<>Off)) then _
WScript.echo XS & vbCrLf & S & vbCrLf
XS = S : XOff = Off
End Sub

WScript.echo " Check every UTC mid-minute for three years :" & _
vbCrLf & " In the EU all offset changes are at 01:00 GMT/UTC," & _
vbCrLf & " on the last Sunday of March/October." & vbCrLf
D0 = CDate("2015/12/31 12:00:30") '' Represents UTC
for K = 0 to 3*366*1440 : SubRtn2(K/1440) : next '' step minutes

WScript.echo " In my UK PCs, time shift date/times are :-" & vbCrLf & _
" Win7 & Win7 XP VM, & UK WinXP, Autumn - one hour late." & vbCrLf & _
" 2 * Win10, Spring and Autumn - OK."

WScript.echo vbCrLf & "End of TIME-BUG.VBS"


*** I have since seen that this bug was reported last year by a user in
*** mainland Europe, where civil time is always an hour ahead of UK time.