Re: CTime getting skewed due to regional settings
I am writing to a DateTime field but via a dynamically constructed SQL
statement:
String sql("INSERT INTO WorkflowAction (ID, WorkflowID, FilterID, SeqNo,
ReceiveByDate, Path ) VALUES(");
sql.append(ToString<KeyId>(req->GetKey()));
sql.append(1,',');
sql.append(ToString<KeyId>(workflow->GetKey()));
sql.append(1,',');
sql.append(ToString<ActionID>(eRequest));
sql.append(",1,",3); // seq # - request always first
sql.append(1,'\'');
sql.append( req->GetReceiveByDate().ToDBString());
sql.append(1,'\'');
sql.append(1,',');
sql.append(1,'\'');
sql.append( req->GetDocument()->GetPath().c_str());
sql.append(1,'\'');
sql.append(")");
conn->ExecuteSQL(sql.c_str());
But what has changed now is I call ToDBString, which uses the following
String DateTime::ToDBString()const
{
struct tm timeinfo;
char timebuf[26];
memset(timebuf,0,26);
errno_t errNo = localtime_s(&timeinfo, &mRawTime);
assert(errNo == 0 );
strftime(timebuf,26,"%Y-%m-%d ",&timeinfo);
return timebuf;
}
as opposed to previously using the ToString function which used the following
strftime(timebuf,26,"%x",&timeinfo);
The ToString is still used within the presentation layer and dates are
correctly diplayed in host locale, but now when i write the dates they are
locale neutral, this allows them to then be interpreted correctly relative to
the locale when read back in.
Hope this makes sense?
"Giovanni Dicanio" wrote:
"PRMARJORAM" <PRMARJORAM@discussions.microsoft.com> ha scritto nel messaggio
news:1B6D7EDA-0C73-4140-B857-1D06D6A03332@microsoft.com...
It seems i may have solved this problem with a little help from various
articles and forums on the iternet.
Would seem you need to write the date in a common format such as
YYYY-MM-DD,
rather than in your host locale. On reading it back in, it is adjusted
accordingly to the hosts locale.
I just hope the above format works on ORACLE too?
I thought you had a need to write dates using an /ad hoc/ type, as SQL
Server DATETIME (which I think is stored in a binary format, maybe
BINARY(8)).
Of course, writing the date as a pure string, with a predefined fixed
format, will work, because I think every database can store strings :)
Giovanni