Consider the following code:
procedure Test;
function d1: Variant;
var
DDt: TDateTime;
begin
DDt := EncodeDate(100,1,1);
Result := DDt;
end;
function d2: Variant;
var
DDt: TDateTime;
begin
DDt := EncodeDate(99,12,31);
Result := DDt;
end;
procedure Writedate(V: Variant);
begin
Writeln(string(V));
end;
var
V: Variant;
begin
V := d1;
Writedate(V);
V := d2;
Writedate(V);
end;
The first call to Writedate will succeed, and the output will be '01-01-0100'. The second call, however, will fail with an 'invalid argument' failure. Inspecting the code, you can see the Variant of the 99-12-31 date has a EVariantInvalidArgError error.
However, if I call FormatDateTime('c', TDateTime(V)) on either TDateTime, they will both succeed. In fact, at any point when the Variant contains a TDateTime, whose date is before 100 CE, the IDE will display a EVariantInvalidArgError when inspecting its value.
It seems odd that the Variant cannot handle the pre-100 CE date, when TDateTime can. Is this a bug in Delphi? I find it being right between 99 and 100 CE to be a bit suspicious.
Variant can contain any date value, as your code demonstrates (assignment V := d2; produces no error).
The error is raised during the conversion to string which the compiler delegates to the OS on Windows platforms. This fails because OLE Automation specifies midnight, 1 January 0100 as the minimum valid OLE Automation date value.
Related
Why DateTimeToMilliseconds in DateUtils.pas is marked as internal?
Can I use it?
{ Internal, converts a date-time to milliseconds }
function DateTimeToMilliseconds(const ADateTime: TDateTime): Int64;
var
LTimeStamp: TTimeStamp;
begin
LTimeStamp := DateTimeToTimeStamp(ADateTime);
Result := LTimeStamp.Date;
Result := (Result * MSecsPerDay) + LTimeStamp.Time;
end;
[Delphi XE]
I have found this on About.com:
Experience shows that creating two TDateTime values using the function and EncodeDateTime that are distant from each other only a millisecond, the function returns a MillisecondsBetween not return as was expected, proving that it is not accurate.
So, if I don't care about few milisecs, I should use it.
The TDateTime is a floating point double. To minimize rounding errors when working with TDateTime values, most calculations in DateUtils converts the TDateTime to milliseconds.
Later when calculations are ready the Int64 value is converted back to a TDateTime value again.
The internal marking is to emphasize that this function is an implementation detail, not to be utilized outside the library. That is, when working with TDateTime values, use the public functions/procedures.
This is a little test of the function MilliSecondsBetween:
program TestMSecBetween;
{$APPTYPE CONSOLE}
uses
System.SysUtils,System.DateUtils;
var
d1,d2 : TDateTime;
i,iSec,iMin,iHour,iMSec;
isb : Int64;
begin
d1 := EncodeDateTime(2013,6,14,0,0,0,0);
for i := 0 to 1000*60*60*24-1 do
begin
iHour := (i div (1000*60*60)) mod 24;
iMin := (i div (1000*60)) mod 60;
iSec := (i div 1000) mod 60;
iMSec := i mod 1000;
d2 := EncodeDateTime(2013,6,14,iHour,iMin,iSec,iMSec);
isb := MilliSecondsBetween(d2,d1);
if (isb <> i) then
WriteLn(i:10,iHour:3,iMin:3,iSec:3,iMSec:4,isb:3);
end;
ReadLn;
end.
You can expand the test for more than one day to see if there are some anomalies.
There's no reason you could not use it, it is not deprecated and used internally.
It's just marked as 'internal' because the function header is not in the interface section. If you copy the header there it should work.
What we always do if we 'patch' a third-party unit like this, is copying it to a directory in our own search path (named PatchLibs) before modifying. That way you can't 'damage' the original file and you don't have to worry about how to rebuild the original units.
I am having one Delphi XE2 Project to check one Hexadecimal Value from Registry Key MyCompanyName\1. If the Hexadecimal Value is 13, then some message will be there else some other message will be there.
So I have defined the following codes:
procedure TMainForm.BitBtn01Click(Sender: TObject);
var
RegistryEntry : TRegistry;
begin
RegistryEntry := TRegistry.Create(KEY_READ or KEY_WOW64_64KEY);
RegistryEntry.RootKey := HKEY_LOCAL_MACHINE;
if (RegistryEntry.KeyExists('SOFTWARE\MyCompanyName\1\')) then
begin
if (RegistryEntry.OpenKey('SOFTWARE\MyCompanyName\1\',true)) then
begin
if (RegistryEntry.ReadString('SettingValue') = '0x00000013') then
begin
Memo01.Lines.Add('SettingHexadeciamlValue exist properly')
end
else
begin
Memo01.Lines.Add('SettingHexadeciamlValue does not exist properly')
end;
end
else
begin
if (RegistryEntry.OpenKey('SOFTWARE\MyCompanyName\1\',false)) then
begin
Memo01.Lines.Add('Unable to read RegistryKey ''MyCompanyName''Exiting.......')
end;
end;
end
else
begin
Memo01.Lines.Add('RegistryKey ''MyCompanyName'' does not exist')
end;
end;
After compilation, when I am running the application AsAdministrator, I am getting error mentioning Invalid data type for 'SettingValue'.
These values are integers, not strings, so you should use ReadInteger, not ReadString.
Now, hexadecimal is only a way of presenting an integer to the user, that is, a method of creating a 'textual representation' of the integer. For example, the integer 62 has many different textual representations:
62 (decimal)
LXII (Roman numerals)
3E (hexadecimal)
111110 (binary)
Sextiotvå (Swedish words)
etc.
If you want to display this number in hexadecimal, as the registry editor (regedit.exe) does, you can use the IntToHex function, which creates a hexadecimal textual representation of the argument integer. Example:
var
myvalue: integer;
...
myvalue := ReadInteger('SettingValue');
ShowMessage(IntToHex(myvalue, 8));
TNumberbox and TSpinEdit return values defined as type single. I want to use these values to do simple integer arithmetic, but I can't cast them successfully to the more generalized integer type, and Delphi gives me compile-time errors if I try to just use them as integers. This code, for example, fails with
"E2010 Incompatible types: 'Int64' and 'Extended'":
var
sMinutes: single;
T: TDatetime;
begin
sMinutes :=Numberbox1.value;
T :=incminute(Now,sMinutes);
All I want to do here is have the user give me a number of minutes and then increment a datetime value accordingly. Nothing I've tried enables me to use that single in this way.
What am I missing??
Just truncate the value before using it:
var
Minutes: Integer;
T: TDateTime;
begin
Minutes := Trunc(NumberBox1.Value);
T := IncMinute(Now, Minutes);
end;
Depending on your particular needs, you may need to use Round instead. It will correctly round to the nearest integer value, making sure that 1.999999999999 correctly becomes integer 2; Trunc would result in 1 instead. (Thanks to Heartware for this reminder.)
var
Minutes: Integer;
T: TDateTime;
begin
Minutes := Round(NumberBox1.Value);
T := IncMinute(Now, Minutes);
end;
Trunc and Round are in in the System unit.
This is not exactly a straight-out question because I have just solved it, but more like "am I getting it right" type of question and a reminder for those who might get stuck into that.
Turns out, Delphi does not align variables on stack and there are no directives/options to control this behavior. Default COM marshaller on my XP SP3 seem to require 4-byte alignment when marshaling records though. Worse, when it encounters unaligned pointer, it does not return an error, oh no: it rounds the pointer down to the nearest 4-byte boundary and continues like that.
Therefore, if you pass a record you have allocated on stack into COM-marshaled function by reference, you're screwed and you won't even know.
The problem can be solved by using New/Dispose to allocate records, as memory managers tend to align everything at 8 bytes or better, but god, this is annoying, both the misalignment part and the "trim-down-pointers" part.
Is this really the reason, or am I wrong somewhere?
Update: How to reproduce (Delphi 2007 for Win32).
uses SysUtils;
type
TRec = packed record
a, b, c, d, e: int64;
end;
TDummy = class
protected
procedure Proc(param1: integer);
end;
procedure TDummy.Proc(param1: integer);
var a, b, c: byte;
rec: TRec;
begin
a := 5;
b := 9;
c := 100;
rec.a := param1;
rec.b := a;
rec.c := b;
rec.d := c;
writeln(IntToHex(integer(#rec), 8));
readln;
end;
var Obj: TDummy;
begin
obj := TDummy.Create;
try
obj.Proc(0);
finally
FreeAndNil(obj);
end;
end.
This gives odd result address, clearly not aligned on anything. If it doesn't, try adding more byte variables to "a, b, c: byte" (and don't forget to simulate some work with them at the end of the function).
The part with COM is easier to reproduce but longer to explain. Create a new VCL app called Sample Server, add a COM object SampleObject implementing ISampleObject, with a type library, free-threaded, single instance (make sure to check ISampleObject is marked as Ole Automation in type library). Open the type library, declare a new SampleRecord with five __int64 fields. Add a SampleFunction with a single SampleRecord* out parameter to ISampleObject. Implement SampleFunction in TSampleObject by returning fixed values:
function TSampleObject.SampleFunction(out rec: SampleRecord): HResult;
begin
rec.a := 1291;
rec.b := 742310;
//...
Result := S_OK;
end;
Note how Delphi declares SampleRecord as "packed record" in automatically generated type library header code:
SampleRecord = packed record
a: Int64;
b: Int64;
//...
end;
I have checked, and this, at least, was fixed in Delphi 2010. Automatically generated records are not packed there.
Register the COM server. Run it.
Now modify the source above (sample 1) to call this server instead of just doing writeln:
uses SysUtils, Windows, ActiveX, SampleServer_TLB;
procedure TDummy.Proc(param1: integer);
var a, b, c: byte;
rec: SampleRecord;
Server: ISampleObject;
begin
a := 5;
b := 9;
c := 100;
rec.a := param1;
rec.b := a;
rec.c := b;
rec.d := c;
Server := CoSampleObject.Create;
hr := Server.SampleFunction(rec);
writeln('#: 'IntToHex(integer(#rec), 8)+', rec.a='+IntToStr(rec.a));
readln;
end;
var Obj: TDummy;
begin
CoInitializeEx(nil, COINIT_MULTITHREADED);
obj := TDummy.Create;
try
obj.Proc(0);
finally
FreeAndNil(obj);
CoUninitialize();
end;
end.
Observe that when the address of rec is not aligned, values of rec fields are wrong (specifically, bitshifted to 8, 16 or 24 bits, sometimes wrapped over to the next value).
Do you have an example of the stack being misaligned? Delphi should be aligning everything to 4 byte boundaries. The only case I can think of that would cause misalignment is if someplace along the call-chain is some assembler code that has explicitly done something to the stack to mis-align it.
var
tm : string;
dt : tdatetime;
tm := '2009-08-21T09:11:21Z';
dt := ?
I know I can parse it manually but I wonder if there is any built-in function or Win32 API function to do this ?
I don't know why there are so many people shooting their mouth off when they don't know what they are talking about? I have to do this menial work; Is it a RAD tool? I sometimes find Delphi has a real superb architecture, though.
procedure setISOtoDateTime(strDT: string);
var
// Delphi settings save vars
ShortDF, ShortTF : string;
TS, DS : char;
// conversion vars
dd, tt, ddtt: TDateTime;
begin
// example datetime test string in ISO format
strDT := '2009-07-06T01:53:23Z';
// save Delphi settings
DS := DateSeparator;
TS := TimeSeparator;
ShortDF := ShortDateFormat;
ShortTF := ShortTimeFormat;
// set Delphi settings for string to date/time
DateSeparator := '-';
ShortDateFormat := 'yyyy-mm-dd';
TimeSeparator := ':';
ShortTimeFormat := 'hh:mm:ss';
// convert test string to datetime
try
dd := StrToDate( Copy(strDT, 1, Pos('T',strDT)-1) );
tt := StrToTime( Copy(strDT, Pos('T',strDT)+1, 8) );
ddtt := trunc(dd) + frac(tt);
except
on EConvertError do
ShowMessage('Error in converting : ' + strDT);
end;
// restore Delphi settings
DateSeparator := DS;
ShortDateFormat := ShortDF;
TimeSeparator := TS;
ShortTimeFormat := ShortTF;
// display test string
ShowMessage ( FormatDateTime('mm/dd/yyyy hh:mm:ss', ddtt) );
end;
http://coding.derkeiler.com/Archive/Delphi/comp.lang.pascal.delphi.misc/2006-08/msg00190.html
If you are using Indy 10, its StrInternetToDateTime() and GMTToLocalDateTime() functions (in the IdGlobalProtocols unit) can parse ISO-8601 formatted strings.
This looks like an internet protocol related activity, so you should have no problems in using the Win32 API for this. However note, that Windows does not correctly support conversion to/from UTC for historical dates that are more than approximately 20 years old - Windows simply doesn't have enough details in its time zone settings for that.