Time-Values

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello NG!

In my ppc-app i've a textbox, where I want the user to input a time-value,
which is stored in a DataColumn with the DataType System.DateTime.
(Country-Setting of the device is "Germany")

If I try to parse the input "17:00" with

"CDate(...).ToLocalTime" it returns "18:00:00"
"CDate(...).ToUniversalTime" it returns "16:00:00"

??? Which one is the right value or how can I get it?

If I enter "27.01.04 17:00" it returns ""27.01.04 XX:00" . But I only need
the time-part of the DateTime-structure, because later the value is stored
in an MS Access-DB with a "Time"-Format an causes trouble if there is a
date-part in it.

Thanks for any suggestion!

D.Barisch
 
In my ppc-app i've a textbox, where I want the user to input a time-value,
which is stored in a DataColumn with the DataType System.DateTime.
(Country-Setting of the device is "Germany")

If I try to parse the input "17:00" with

"CDate(...).ToLocalTime" it returns "18:00:00"
"CDate(...).ToUniversalTime" it returns "16:00:00"

??? Which one is the right value or how can I get it?

Well, what does the 17:00 represent? If it's a local time, then calling
ToUniversalTime will give the universal time. If it's a universal time,
then calling ToLocalTime will give the local time. Not calling anything
will leave it as it is.
If I enter "27.01.04 17:00" it returns ""27.01.04 XX:00" . But I only need
the time-part of the DateTime-structure, because later the value is stored
in an MS Access-DB with a "Time"-Format an causes trouble if there is a
date-part in it.

Well, how are you presenting the data to the Access DB? If it's a
parameter, I'd expect the provider to use only the appropriate part of
the DateTime.
 
Well, what does the 17:00 represent? If it's a local time, then calling
ToUniversalTime will give the universal time. If it's a universal time,
then calling ToLocalTime will give the local time. Not calling anything
will leave it as it is.
17:00 should represent a time the user enters. If he wants to have an
appointment at 17:00 he won't enter 16:00 or 18:00. So why do I get
differences between CDate(...) and CDate(...).ToLocalTime. That's really
confusing to me!
Well, how are you presenting the data to the Access DB? If it's a
parameter, I'd expect the provider to use only the appropriate part of
the DateTime.
The values are stored to the Access-DB manually. That means I walk through
every column of every row in the DataSet like

for each pRow in pDataTable
GoToRightRecord(pRs) '(or something like that)

for each pCol in pRow
pRs.Fields(pCol.ColumnName) = pRow(pCol))
next pCol
next pRow

where pRs is an ADODB.Recordset!

Sorry but I have to go this way, because I'm not 'allowed' to write directly
to the DataBase with Ado.NET. Instead I have to use a DataLayer
(.NET-Project), which was implemented some time ago...

So is it possible to store only Time-Values in a DataColumn or do have to do
an extra-job for such fields in my synchronsation-process?

Thank, D.Barisch
 
17:00 should represent a time the user enters. If he wants to have an
appointment at 17:00 he won't enter 16:00 or 18:00. So why do I get
differences between CDate(...) and CDate(...).ToLocalTime. That's really
confusing to me!

ToLocalTime assumes that the original DateTime is in universal time.
ToUniversalTime assumes that the original DateTime is in local time.
Basically one adds an offset, the other takes it away.
The values are stored to the Access-DB manually. That means I walk through
every column of every row in the DataSet like

for each pRow in pDataTable
GoToRightRecord(pRs) '(or something like that)

for each pCol in pRow
pRs.Fields(pCol.ColumnName) = pRow(pCol))
next pCol
next pRow

where pRs is an ADODB.Recordset!

Sorry but I have to go this way, because I'm not 'allowed' to write directly
to the DataBase with Ado.NET. Instead I have to use a DataLayer
(.NET-Project), which was implemented some time ago...

So is it possible to store only Time-Values in a DataColumn or do have to do
an extra-job for such fields in my synchronsation-process?

I don't know about ADODB, I'm afraid.
 
ToLocalTime assumes that the original DateTime is in universal time.
ToUniversalTime assumes that the original DateTime is in local time.
Basically one adds an offset, the other takes it away.
Uhm, yes now I got it.

If I parse the Input with

CDate(System.DateTime.MinValue.Date & " " & CDate(...).ToString("HH:mm")

it works!

Whereas I don't really understand why this expression returns a Date...

D.Barisch
 
Back
Top