Plugin Scripting BUG: Problem using dates and floating point

[pmk65]

In my latest plugin, I have a line:
var UnixStartDate = StrToDate("01/01/1970");

This works perfectly on my system, but on other systems it reports an error:
Plugin "Unix Timestamp": Line 28:5: "01/01/1970" is not a valid date

I had a similar problem a while ago, working with floating point values.
It looks like WeBuilder uses the system settings of the computer.

In Denmark where I live, we use comma as thousand seperator and point as decimal seperator and slash as date separator.
But in the US they use point as thousand separator and comma as decimal seperator.

So my plugin will work in the countries who uses the same separators as me, and fail with an error in all other countries.

[pmk65]

I have discovered why this problem happens.
According to this site (which I use a LOT as reference when writing plugins), the default separator between dates is defined like this:
http://www.delphibasics.co.uk/RTL.asp?N ... eSeparator

DateSeparator = LOCALE_SDATE by default.

Now this poses is a BIG problem, as FastScript/WeBuilder doesn't have the commands (like: DateSeparator, TimeSeparator, ShortTimeFormat, LongDateFormat ect.) to change that.
So the values used in a plugin script can change depending on the users language setup in Windows.

This makes it hard/impossible to create plugins that use floating point or date/time operations.

[Aivars]

I'll add "DateSeparator, TimeSeparator, ShortTimeFormat, LongDateFormat" to plugins wishlist. We didn't figure someone would do a lot of date/time manipulations

[Aivars]

Btw there should be no problems with decimal values any more, WeBuilder just resets it to "." independent on locale (because Web standards e.g. CSS use . anyways). It's more complicated with the dates, I think your idea of exposing date format would be better in this case.

[pmk65]

Good to know that the floading point problem has been fixed.

I got around the Date problem by using a numeric value instead of the date object. But that only worked when converting from Unixtimestamp to date.
The other way (date to untixtimestamp) requires a known dateformat.

[Aivars]

The 4 listed functions will be added, but only in Read-only mode. There are some functions that have been there since the beginning, that might help you with dates:

Code: Select all

function EncodeDate(Year, Month, Day: Word): TDateTime
procedure DecodeDate(Date: TDateTime; var Year, Month, Day: Word)
function EncodeTime(Hour, Min, Sec, MSec: Word): TDateTime
procedure DecodeTime(Time: TDateTime; var Hour, Min, Sec, MSec: Word)
function Date: TDateTime
function Time: TDateTime
function Now: TDateTime
function DayOfWeek(aDate: TDateTime): Integer
function IsLeapYear(Year: Word): Boolean
function DaysInMonth(nYear, nMonth: Integer): Integer
function FormatDateTime(Fmt: String; DateTime: TDateTime): String
function ValidDate(cDate: String): Boolean

and these are the ones that you know about, but I'm adding them here for reference:

Code: Select all

function DateToStr(e: Extended): String
function TimeToStr(e: Extended): String
function DateTimeToStr(e: Extended): String
function StrToDate(s: String): Extended
function StrToTime(s: String): Extended
function StrToDateTime(s: String): Extended

[pmk65]

From the documentation of "StrToDateTime" (The other StrToXX functions is similar)

---
The first, date part of the string must adhere to the format of the ShortDateFormat value, and use the DateSeparator character to separate the day, month and year values.

The second, time part, separated by a blank from the date must adhere to the format of the LongTimeFormat value, and use the TimeSeparator character to separate the hour, minute and second values.
---

So I don't think a ReadOnly version will help. As without having a unified ShortDateFormat ,LongTimeFormat, TimeSeparator and DateSeparator it will be very hard to make a conversion that works on all setups.

[Aivars]

In your specific case you could use EncodeDate(1970, 1, 1) and avoid StrToDate altogether. If you are targeting a specific, locale-independent format, you could use regular expressions to split the date/time string into the components and then use EncodeDate(...) + EncodeTime(...).

[pmk65]

In your specific case you could use EncodeDate(1970, 1, 1) and avoid StrToDate altogether. If you are targeting a specific, locale-independent format, you could use regular expressions to split the date/time string into the components and then use EncodeDate(...) + EncodeTime(...).

Didn't think of that. Thanks.

BTW: Then I found a way to get hold of the locale settings of the system using a batch file. And then it's easy to pass the output to a plugin script.

Code: Select all

@ECHO OFF
FOR /F "tokens=2*" %%A IN ('REG QUERY "HKEY_CURRENT_USER\Control Panel\International" /v sTimeFormat') DO SET TimeFormat=%%B
FOR /F "tokens=2*" %%A IN ('REG QUERY "HKEY_CURRENT_USER\Control Panel\International" /v sLongDate') DO SET LongDate=%%B
FOR /F "tokens=2*" %%A IN ('REG QUERY "HKEY_CURRENT_USER\Control Panel\International" /v sShortDate') DO SET ShortDate=%%B
FOR /F "tokens=2*" %%A IN ('REG QUERY "HKEY_CURRENT_USER\Control Panel\International" /v sDate') DO SET DateDelimiter=%%B
FOR /F "tokens=2*" %%A IN ('REG QUERY "HKEY_CURRENT_USER\Control Panel\International" /v sTime') DO SET TimeDelimiter=%%B

ECHO TimeFormat    = %TimeFormat%
ECHO LongDate      = %LongDate%
ECHO ShortDate     = %ShortDate%
ECHO DateDelimiter = %DateDelimiter%
ECHO TimeDelimiter = %TimeDelimiter%