LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Find UTC offset for pacific timezone

I have two file names,
GST564_14Mar10_01-50-35.RAW
GST564_14Mar10_03-06-42.RAW

The file name contains the date the file was created on the server.  The server time is Pacific Time, either PST or PDT.  In this example, the first is in PST and the second is in PDT.

I need a vi to convert the time to UTC according to the timezone rules for Pacific Time, and then display the time using the local time of the computer (regarless of its timezone).  You can see in the vi how I do this manually in the attached vi. Is there a way to use the various date/time functions to figure out whether the offset should be 7 or 8 based on the name/time?

 

Thanks.

-Dan

0 Kudos
Message 1 of 17
(4,458 Views)

Hi Dan,

 

I'm confused.  What do you want the new VI to do that this one doesn't?  Can you give an example of how this VI is supposed to work? 

0 Kudos
Message 2 of 17
(4,437 Views)

DirtDr,

 

It doesn't appear there is anything in the filename that indicates timezone. 

Is there something in the file data that provides that detail?

That is how do you which file is PST & PDT?

 

James

LabVIEW 5.0 seems so long ago...
0 Kudos
Message 3 of 17
(4,429 Views)

Smootastic wrote:

Hi Dan,

 

I'm confused.  What do you want the new VI to do that this one doesn't?  Can you give an example of how this VI is supposed to work? 


I guess the OT would want to calculate the timezone offset for a timezone different than his current computer timezone. This is IMHO not possible with any functionality in LabVIEW and in fact not even in Windows, unless you count the possibility to change the current timezone temporarily through Windows API calls for the duration of the calculation as a valid option, which I wouldn't

 

The information if it is PDT or PST is inherent in the timestamp itself since the switch usually happens between 2 and 3 AM local time, and the LabVIEW timestamp conversion functions since around LabVIEW 7 or 8 work correctly for that as long as you refer to the currently set timezone.

Message Edited by rolfk on 04-22-2010 09:21 PM
Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 4 of 17
(4,424 Views)

Thanks for the replies.

 

There's nothing in the name that states the timezone - I just know that it's Pacific Time because that's where the server is.  I just need labview to tell me the UTC offset for pacific time based on the time from the file name.  I know how to get Labview to tell me the UTC offset for my local machine, but I can't figure out how to specify a specific time zone other than my local machine or UTC.

 

The code I posted works, I just want the vi to figure out programmatically whether the offset should be 7 or 8 rather than using the GUI.

-Dan

0 Kudos
Message 5 of 17
(4,405 Views)

Dan,

 

How do you 'manually' determine if the file is a 7 or 8 hour offset?

Without knowing that it is difficult to suggest how to automate that part of the process.

 

James

LabVIEW 5.0 seems so long ago...
0 Kudos
Message 6 of 17
(4,399 Views)

I can manually look up on a table somewhere whether it is PST or PDT based on the time in the file name.  I could program a lookup table but that seemed excessive for something that I figured would be built in if I were clever enough to find it 🙂

 

I am thinking I could try assuming it is PST, add 8 to my timestamp to convert to UTC, use the "isDST" function to see if that UTC time is daylight savings time on the local machine, then if it is I could go back and add 7 instead of 8.  I think this will work as long as the local machine observes DST, which may be enough for us (I could put a disclaimer to that regard, too).  I just have to find the time to figure out how to use isDST now 🙂

 

Any better ideas?

 

Thanks for all the feedback.

-Dan

0 Kudos
Message 7 of 17
(4,385 Views)
Well as long as you are in the US you should be save in assuming that the DST switch over is at the same time. So you should end up with a constant offset from your timezone to the timezone you are interested in and therefore could simply account for that offset.
Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 8 of 17
(4,376 Views)

rolfk wrote:
Well as long as you are in the US you should be save in assuming that the DST switch over is at the same time. ...

Unless you are in Arizona where we do not observe DST.  (and I'm glad we don't)

Isn't there another state that doesn't observe DST, some farming state, maybe Iowa?

 

- tbob

Inventor of the WORM Global
0 Kudos
Message 9 of 17
(4,374 Views)

Dan,

 

OK, I was misunderstanding your request.

Do the file go back before the last change in Daylight Savings Time dates (2007)?

If not, here's the limits:

 

Effective in the US in 2007 as a result of the Energy Policy Act of 2005, the local time changes from PST to PDT at 02:00 LST to 03:00 LDT are on the second Sunday in March and the time returns at 02:00 LDT to 01:00 LST on the first Sunday in November.

 

There is not a simple way to make this automated and flexible to the PC's local time.

However, you can determine the initial time zone with fairly simple, but not quick to write, code.

 

1) Find the year of the fileand create complete timestamp

2) Find the date for the Sundays and create timestamps

3) Compare timestamps to determine if PST or PDT

4) Adjust file timestamp to UTC (subtract 7 or 8 hours)

5) Convert back to PCs local time

 

However, if you have any control over the file naming, save as UTC in filename.

Then all this effort is unnecessary and the code in LabVIEW is simple.

I attached an example that shows how simple this would be with UTC in the filename.

In addition, I placed an extra TimeZones control that might be handy as a reference.

 

Good Luck,

 

James

 

LabVIEW 5.0 seems so long ago...
0 Kudos
Message 10 of 17
(4,364 Views)