GetDate/time on win7 different form regional sys settings?

[Dick99999]

My win 7 has been set to English (UK). Date and time format in regional settings are: dd/MM/yyy and HH:mm
examples 10/9/2010 (tenth of sep) and 17:30 hour

Getdate>and getime> in MS display 9/10/2010 and 5:28:47 PM

Any way to make the MS output the same as the system settings?

[JRL]

Try using VBScript instead of Macro Scheduler functions. The great thing about the Macro Scheduler functions is that they are portable without the need to worry about the individual PC's regional settings.

Code: Select all

VBSTART
VBEND
VBEval>Date(),TheDate
VBEval>Time(),TheTime
VBEval>Now(),Both

[Dick99999]

........ The great thing about the Macro Scheduler functions is that they are portable without the need to worry about the individual PC's regional settings........

Perhaps this is a bug then. It is a compiled script on win XP, that runs OK, in 24H format on XP. When I run that script on win 7, it runs in 12H &MDY mode.

In this case I'd favor an overwrite by the system settings over portability though. And that is what the MS help file suggests for these functions. However, even though both machines have 24h & DMY format in system settings, the result on win 7 is not equal to those system settings (and not equal to 'portable').

[JRL]

I haven't tried on Win7 yet. I believe Marcus has always told people to use the Sec>, Min>, Hour>, Day>, Month> and Year> functions when they require consistency between computers. They return fixed values no matter the regional settings. I was thinking GetDate> and GetTime> did also but based on what I just read in help, apparently I was wrong.

Try these and let us know if you get consistency. I believe that Year> always returns a four digit year. The rest always return two digits. Hour is always based on a 24 hour clock.

Code: Select all

Year>yyyy
Month>mm
Day>dd
Hour>hh
Min>mn
Sec>ss

Let>now=%dd%\%mm%\%yyyy% %hh%:%mn%:%ss%

[Dick99999]

Thanks, indeed that works. So the compiled cript on XP gives consistent results now when running on XP and on Win7s (both UK and NL).

The only remark I'd like to make is that little by little I have to embed a lot of functionality in subroutines to get rid of side effects of and sometimes of bugs I believe in, standard MS functions.
What's the experience of other users? Is this something one should expect when using a macro language?

[Marcus Tettmar]

The help topic for GetTime says:

"The format of the time depends on the regional settings of the system."

The help topic for GetDate says:

"The format of the date depends on the regional settings of the system."

Dates and times can take all kinds of formats, some by global location and by personal preference. So in ANY language if you want a function that returns a whole date/time then either it must make an assumption, use the current system settings, or take another parameter that allows you to define it. And in the latter it may then not match the system format that the user chose. The polite thing to do is return it in the format the user chose, which is why we always return, by default, the system settings. Windows works that way. So Macro Scheduler returns the date in the system format (i.e. as per the user's preference).

If you need to have absolute control over the exact format then of course you'll have to define that yourself and therefore you'll need to use the individual commands Year, Month, Day, Hour, Min, Sec to get the parts you want and then concatinate them how you want. There are many other date functions available in VBScript too including one to format a date in a number of different ways. So you have internal control over a date for accuracy and also ways to display it to the user in a way he may be familiar with.

Call this a bug if you must but to me it is common sense .... and more to the point it is as documented as can be seen from my quotes above.

[Dick99999]

The help topic for GetTime says:

"The format of the time depends on the regional settings of the system."

The help topic for GetDate says:

"The format of the date depends on the regional settings of the system."

[... deleted tex ....]

.... and more to the point it is as documented as can be seen from my quotes above.

Strangely I agree ... almost. I think you missed my original point which was exactly that the help documentation says what is quoted. However, MS on Win 7 seems NOT to behave like that, while XP does. I believe it's common sense to describe such a feature as a bug. -)

To be sure I tested this both in a cross compiled script and in a debug-run script. My original mail is also true for regional settings NL.

My win 7 has been set to English (UK). Date and time format in regional settings are: dd/MM/yyy and HH:mm
examples 10/9/2010 (tenth of sep) and 17:30 hour

Getdate>and getime> in MS display 9/10/2010 and 5:28:47 PM

Any way to make the MS output the same as the system settings?

[Marcus Tettmar]

I'm unable to replicate what you observe. I'm running Win7 x64 Ultimate. I opened up regional settings and whatever I set the settings to GetDate and GetTime always observed.

I also did the same in XP and get the same results. Both XP and Win7 are observing the regional settings.

GetDate and GetTime are calling Windows System functions. *WE* do nothing to the values returned. We're simply calling system functions to return the system date and time.

[gdyvig]

Perhaps it is a Delphi error on which Macro Scheduler is based. Google on "delphi windows 7 regional settings" and you will find some articles on delphi ignoring some date/time settings.

Gale

[Marcus Tettmar]

Doubt it's Delphi. These are just wrappers to Windows own functions. These functions call the Windows function GetLocaleInfo to get the format strings:

http://msdn.microsoft.com/en-us/library ... S.85).aspx

E.g.

LOCALE_SSHORTDATE (1F)

If the local strings cannot be found then the functions fall back on default values. I'm guessing you're getting the default values. Which would mean something's not right with your registry/system and the valid format values aren't present.

You might want to try re-resetting your regional settings to make sure they are stored correctly. Try going into control panel - region and language and then change the short date and long time settings, hit apply, then change them back again to your preference and hit apply again.

I've looked closely at our code and Delphi's code and it's really all just calling the system functions and looking up Window's own values. So any problem must be being caused by Windows.

I found this which corroborates my theory that there's a bug with Windows 7:

https://forums.embarcadero.com/thread.j ... adID=29082

See the last post for details:

Hi Drew,

the whole storry is due to a bug occouring on some Win7 systems not storing the regional settings correctly, even though they seem to be set propperly.

WORKAROUND:
1) Start/Configuration/Regional settings (: the globe symbol
2) on the 1st tab select a different country, i.e. Germany and press [APPLY]
3) set the country back to what it should be and press [OK]
4) Now your app will behave again as expected.

The actual bug is a invalid return value of GetThreadLocale() which returns a different language id than your system is or better seems to be configured for.
I have tested this with a small application returning me decimalseparator and thousandseparator which was in our case the english notation instead of the german/dutch one.

See also TBurrowsNZ comment here http://social.technet.microsoft.com/For ... 17bfa689e0

I hope this will fix your problem as well.

GetThreadLocale is a function in Windows:
http://msdn.microsoft.com/en-us/library ... S.85).aspx

Note the technet link shows a workaround we can use. But note that this appears to be a bug in Windows 7. Not with Delphi or Macro Scheduler.