Re: Finding the offset of a specific time zone

John Warner <[email protected]> Wed, 25 Mar 2009 17:56:33 -0400
Newsgroups gmane.comp.windows.devel.dotnet.advanced
Organization House
Message-ID <01cd01c9ad94$9035cda0$b0a168e0$@com>
No, you can use that in your app to see if California is on daylight
savings or standard time. You already know the utc offset, I thought you
just needed a way to automatically tell if the remote server/sensors are
reporting in standard time or daylight time so you could make the change
to the data on your end before writing to the data store. 

In your code:
If (TT says daylight time) {
	California Offset -= 1
}

Have I misunderstood the problem? I though the question had to do with an
automatic way to tell if California was on daylight time which would
impact the utc offset by a 1. I guess I misunderstood the problem. I
thought you had no control on the remote data reporting side of the
equation. I thought you received the data with the remote server's time
stamp and the receiver was in the east. Problem then to properly time
stamp the data based on the eastern time or better utc. I was of the
impression the fix had to be in your program that you had no or little
control over the other side of the transaction. Sorry for the
misunderstanding. 

John Warner


> -----Original Message-----
> From: Discussion of advanced .NET topics. [mailto:ADVANCED-
> [email protected]] On Behalf Of Peter Ritchie
> Sent: Wednesday, March 25, 2009 3:35 PM
> To: [email protected]
> Subject: Re: [ADVANCED-DOTNET] Finding the offset of a specific time
zone
> 
> It sounds like you're suggesting the client send the date/time stamp to
include
> the TT data, since it's the only one that knows that when it sends the
date/time
> data.  But why?  If you're changing client code to send different data,
just
> convert from local time to UTC and send it.  It's the only reliable way
to store
> date/time data than can be converted to any other local time without
having to
> know the originating timezone.
> 
> Having a config file of daylight time observances is simply too
complicated.
> You can't simply take into account current observances of daylight
savings
> time.  You have to take into account the observances at the date and
time of
> the date/time value.  E.g. the observance in the US changed in 2007 to
the 2nd
> Monday in March from the first Sunday in April.  How do you convert both
of
> the following UTC times correctly: 13-Mar-2006 10AM,  13-Mar-2007 10AM?
> You'd have to have a config file containing all the changes to US
daylight
> savings time observances, look up that one that applies to a particular
> date/time value, and use it for the conversion.  Do you really want to
manage
> that data while the OS on both ends is already doing that?
> 
> -- Peter
> 
> On Wed, 25 Mar 2009 14:18:56 -0400, John Warner
> <[email protected]> wrote:
> 
> >http://tf.nist.gov/service/its.htm
> >
> >See if this helps. Read through the entire page and note the TT portion
of
> >the data and explanation. It appears to have an answer for you as
regards
> >the US in general observing daylight or standard time. If some counties
on
> >the left coast ever decide to go it alone you will once again have an
> >issue.
> >
> >I would be inclined to have a config/dat file that the user can update
> >when daylight time is observed.  Provide a small util to adjust the
time
> >or just a plain text file that can be edited with notepad. Some sort of
> >true false thing would be my thought. Congress every few years likes to
> >play with this. Shows they are important, so you would need to make
some
> >provision for the US political system...
> 
> ===================================
> View archives and manage your subscription(s) at
> http://peach.ease.lsoft.com/archives

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives