468,243 Members | 1,772 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,243 developers. It's quick & easy.

Time zones dates in vb.net 2005

Hi All

I need to compare date times from 2 different states in Australia in a
Program I have which determines which way to update SQl server 2005 tables
based on the lastupdate (datetime field) datetime

Each location updates the lastupdate field based on the current local
datetime at the the time of saving to SQL server

Perth for example is 2 hours behind Melbourne

How is the best way to do this

Convert both times to UTC first?

Regards
Steve
Jul 13 '07 #1
4 3709
Hi All

Further to the above post

The times can change based on the time of year, as not all states in
Australia use daylight saving and those that do don't always change at the
same time

Regards
Steve

"Steve" <ga*****@newsgroups.nospamwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
Hi All

I need to compare date times from 2 different states in Australia in a
Program I have which determines which way to update SQl server 2005 tables
based on the lastupdate (datetime field) datetime

Each location updates the lastupdate field based on the current local
datetime at the the time of saving to SQL server

Perth for example is 2 hours behind Melbourne

How is the best way to do this

Convert both times to UTC first?

Regards
Steve

Jul 13 '07 #2
I see three ways to store the information:

a) Store UTC only (one field). It is sufficient but afterwards you won't
know at which local time offset it has been stored. It is not necessary if
you don't want to know it.
b) Store UTC (one field) and local time offset (+10 or whatever) in another
field.
c) Store local time and local time offset. By subtracting the latter from
the former, you get UTC.
b) and c) are a matter of taste. They contain the same information. I'd
probably go for b). c) is more like what is used in mail headers ("23:17
+1000" is local time + time offset).

Internally, you can always use and calculate with the UTC datetime values.
If you take the current, local date (Datetime.Now) into your calculations,
also convert to UTC before doing the calculations or before storing it in
the DataRow (later Database). Only convert to local time whenever you want
to display the local time, and convert to UTC when converting input to a
DateTime value.

I guess you know that DateTime provides the ToUniversalTime and ToLocalTime
methods.
Armin
Hi All

Further to the above post

The times can change based on the time of year, as not all states in
Australia use daylight saving and those that do don't always change
at the same time

Regards
Steve

"Steve" <ga*****@newsgroups.nospamwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
Hi All

I need to compare date times from 2 different states in Australia
in a Program I have which determines which way to update SQl
server 2005 tables based on the lastupdate (datetime field)
datetime

Each location updates the lastupdate field based on the current
local datetime at the the time of saving to SQL server

Perth for example is 2 hours behind Melbourne

How is the best way to do this

Convert both times to UTC first?

Regards
Steve

Jul 13 '07 #3
Hi Armin

Thanks for the reply

Great explanation

As only the synchronising code uses these dates I have gone with A

I have set the region on 1 computer to 'Perth Australia' and the other is on
'Canberra, Melbourne, Sydney' and it works a treat

Regards
Steve
"Armin Zingler" <az*******@freenet.dewrote in message
news:uE**************@TK2MSFTNGP03.phx.gbl...
>I see three ways to store the information:

a) Store UTC only (one field). It is sufficient but afterwards you won't
know at which local time offset it has been stored. It is not necessary if
you don't want to know it.
b) Store UTC (one field) and local time offset (+10 or whatever) in
another
field.
c) Store local time and local time offset. By subtracting the latter from
the former, you get UTC.
b) and c) are a matter of taste. They contain the same information. I'd
probably go for b). c) is more like what is used in mail headers ("23:17
+1000" is local time + time offset).

Internally, you can always use and calculate with the UTC datetime values.
If you take the current, local date (Datetime.Now) into your calculations,
also convert to UTC before doing the calculations or before storing it in
the DataRow (later Database). Only convert to local time whenever you want
to display the local time, and convert to UTC when converting input to a
DateTime value.

I guess you know that DateTime provides the ToUniversalTime and
ToLocalTime methods.
Armin
>Hi All

Further to the above post

The times can change based on the time of year, as not all states in
Australia use daylight saving and those that do don't always change
at the same time

Regards
Steve

"Steve" <ga*****@newsgroups.nospamwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
Hi All

I need to compare date times from 2 different states in Australia
in a Program I have which determines which way to update SQl
server 2005 tables based on the lastupdate (datetime field)
datetime

Each location updates the lastupdate field based on the current
local datetime at the the time of saving to SQL server

Perth for example is 2 hours behind Melbourne

How is the best way to do this

Convert both times to UTC first?

Regards
Steve


Jul 13 '07 #4
"Steve" <ga*****@newsgroups.nospamschrieb
Hi Armin

Thanks for the reply

Great explanation
Was a pleasure. :-)
As only the synchronising code uses these dates I have gone with A

I have set the region on 1 computer to 'Perth Australia' and the other is
on 'Canberra, Melbourne, Sydney' and it works a treat


Armin

Jul 13 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by David Graham | last post: by
5 posts views Thread by Gord | last post: by
11 posts views Thread by lduperval | last post: by
14 posts views Thread by Cesar Ronchese | last post: by
3 posts views Thread by Satish Itty | last post: by
6 posts views Thread by dredge | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.