Print Page | Close Window

ShiftDateTime DST issues

Printed From: Crystal Reports Book
Category: Crystal Reports 9 through 2020
Forum Name: Technical Questions
Forum Discription: Formulas, charting data, Crystal syntax, etc.
URL: http://www.crystalreportsbook.com/forum/forum_posts.asp?TID=15649
Printed Date: 03 May 2024 at 9:50pm


Topic: ShiftDateTime DST issues
Posted By: turdferguson
Subject: ShiftDateTime DST issues
Date Posted: 16 Feb 2012 at 7:51am
So we are having an issue we cannot resolve here.

I'm running Crystal XI R2 SP6. Updating and rebooting did not solve this issue.

So basically, we are converting from UTC to the customer's time zone. So we do this

ShiftDateTime ({DateTimeField}, ",0,UTC","")

To adjust it to the viewer's time zone. The problem is, this doesn't account for DST at all.

Is there any function/method/update that fixes this? I've been going about doing a giant function checking against hardcoded values if its DST. Before I get too involved in that, does anyone know what I'm talking about or can help?

Thanks! :)


Replies:
Posted By: DBlank
Date Posted: 16 Feb 2012 at 8:12am
not sure but maybe htis will help from Crystal Help file ShiftDateTime (v XI)

Posted By: turdferguson
Date Posted: 16 Feb 2012 at 9:21am
That's the idea. We're using "" to represent the user's local time zone.

Unless something like

ShiftDateTime ({DateTimeField}, ",0,UTC","UTC, 0, DST, 60")

would work, and it doesnt. "time zone field not valid", pointing to the last argument. 

Posted By: turdferguson
Date Posted: 21 Feb 2012 at 4:43am
bump. anyone? 

Posted By: lockwelle
Date Posted: 21 Feb 2012 at 4:56am
not all states use DST, and not all nations either, so I am not sure if there is simple generic solution.
 
a look up table seems the best solution. If every one followed DST, I would have thought that looking up the longitude(not that that is simple) would be a consistent method

Posted By: turdferguson
Date Posted: 21 Feb 2012 at 5:02am
My question is why doesnt Crystal do this conversion built into it? Especially six service packs in? Or is mine just bugged? 

Posted By: rkrowland
Date Posted: 21 Feb 2012 at 5:22am
If I was you, I'd use the dateadd (or the shiftdatetime - I'm not familiar with this function myself so I'd stick to dateadd) function to convert all your times to GMT (as everyone knows how many hours their timezone differs from GMT).
 
Then just place a parameter on the report asking the user how their timezone differs from GMT - GMT-12, GMT-11..... GMT+12.. etc - then adjust your GMT times based on this.
 
Regards,
Ryan.

Posted By: turdferguson
Date Posted: 21 Feb 2012 at 6:14am
We shouldnt have to do that though, and due to the requirements, we cannot. 

Posted By: lockwelle
Date Posted: 21 Feb 2012 at 7:09am
maybe because DST is not standard for any given location, there is no real way to implement it in a simple way.
 
And I know your can't, but my idea and rkrowland are basically the same.  The closest you can get is how far you are from an arbitrary point.
 
Case in point, Arizona does use DST, but states above and below do, nor does Indiana, so how would you apply this.  Do timezones cut through the middle of states? (they should but politics mess with this). While I understand that you need this to work, I don't think that there is a simple implementation, and for a application that is primarily concerned with reporting data, I could make a case that 99.9% of all reports don't need this functionality and so expending the effort for a non-trivial solution is a poor use of resources.
 
Again, I understand that it is in your specs, but what you would need such a function for?  I would think that if you denoted the value as EST or EDT that a locality that wasn't using it would be able to adjust...
 
So adjusting the time and denoting what it is referencing, is about as close as you can come (I think) without massive coding.  I am sure that you can find the rules as to when DST starts and stops and use that to update the time stamp...at least that is what I would advocate for with my superiors along with the number of hours to find a solution that won't make the report run like a dog...maybe a table of every zip code in the US and what time zone they are in and if they follow DST or not...
 
Don't know about Canada at all
 

Posted By: turdferguson
Date Posted: 21 Feb 2012 at 7:36am
Understandable. But really, why doesn't Crystal have this functionality to adjust for DST in the first place?

And all of our reports for one product need this implemented (around 25), so its not a 99.9%...

I'll forward your info along to the powers that be.

Posted By: lockwelle
Date Posted: 21 Feb 2012 at 10:09am
just to be the smartass, out of the 100 reports that I have written, plus probably another 50 - 75 that others have written over the years for our app, we use this functionality in 0...
 
again, just being a smartass. ;)

Posted By: turdferguson
Date Posted: 21 Feb 2012 at 10:13am
:'( Mean! It just so happens this happens to us since we store our dates in AX 2009 and 2012 in UTC.... Dunno if this was an issue before! It was just thrown on my plate and i've scoured all over and was just told to update crystal reports... that didnt work... so i tried posting here while writing some custom code for it.

It's a really stupid issue too. They cant get past how Crystal doesnt do it itself, and I'm tasked with finding out anything I can.

Posted By: lockwelle
Date Posted: 21 Feb 2012 at 10:26am
sorry for your predicament.
 
I was talking with a co-worker, and he was saying there are databases out there that have all the zip codes and some time information. He didn't know if DST was part of that, but it might be an aid / alternative.  I believe he said TigerLine.
 
Another co-worker mentioned that DST is a american/european thing.
 
relations to GMT is easier worldwide, relative to PST or PDT (or any other region) is easier in US, but DST is complex as you might be in the CDT timezone but not follow DST, so you would be CST (again Arizona and Indiana are my examples)...
 
so it just isn't a simple problem to solve
 
HTH

Posted By: rkrowland
Date Posted: 21 Feb 2012 at 10:14pm
How many different timezones have you got to adjust for? How are you identifying which timezone (irrelevant of DST or BST as it's known here in the UK) should be applied without parameters?

Posted By: turdferguson
Date Posted: 22 Feb 2012 at 2:43am
That's the fun part. We have customers for many different time zones worldwide, and of course, many countries dont follow DST so that's where this becomes difficult. 

Posted By: rkrowland
Date Posted: 22 Feb 2012 at 2:59am
Well for examples sake - let's say we could do all the timezone & DST adjustments for your users.
 
How exactly would you determine which of the timezone adjustments is applicable to the user's local timezone without the use of parameters?
 
Even if Crystal could automatically determine timezone adjustments and DST adjustments there'd still be no way to do what you want without atleast 1 parameter where the user must state at the very least where they live. Atleast not to my knowledge.
 
I'm still standing by the +/- hours parameter - it's simple, clean and easy to understand haha!
 
Regards,
Ryan.

Posted By: lockwelle
Date Posted: 22 Feb 2012 at 3:36am
While I realize it is against the specs....
 
I agree with rkrowland...if you are in another country, I am willing to bet that you are already used to converting times from GMT.
 
and while you're not dealing with aviation (i'm willing to bet) all pilots need to be able to convert from GMT as the weather reports are given in GMT...and it's in all the emails as well so it is fairly pervasive.
 
it might confuse us silly Americans, but then you might be able to EST/PST/CST/MST or with D to make them happy.
 
just a thought

Posted By: edmhess
Date Posted: 29 Feb 2012 at 3:20am
I also need this functionality for a global implementation of Charles River IMS where the server will be located in PA but the reports will be run in Melbourne.  I'd like to avoid having end-users set a parameter for their time zone so that DST can be accounted for.  I believe the OS knows what time it is in Melbourne as I can set an option in the Charles River app to Australia/Melbourne and the UIs show their time.  My other option is to offset the time zone on the reporting server in PA but that causes problems for the operations team.
 
As more companies run global operations this will become more of a problem.

Posted By: rkrowland
Date Posted: 29 Feb 2012 at 3:36am
It shouldn't be a major task to do this via a formula for a single timezone adjustment - the reason we advised use of parameters for the OP is because he needed conversions and DST adjustments for various time zones.
 
A formula to check whether the date falls in the DST period, then 2 dateadd formulas to adjust the hours by varying amounts depending on whether or not it falls in the DST period.
 
Regards,
Ryan.

Posted By: turdferguson
Date Posted: 29 Feb 2012 at 3:54am
Originally posted by rkrowland

It shouldn't be a major task to do this via a formula for a single timezone adjustment - the reason we advised use of parameters for the OP is because he needed conversions and DST adjustments for various time zones.
 
A formula to check whether the date falls in the DST period, then 2 dateadd formulas to adjust the hours by varying amounts depending on whether or not it falls in the DST period.
 
Regards,
Ryan.


It's more than just simple dateadd formulas. You have to check second sundays for both November and March.

Even moreso, you'll have to somehow check if its in an area that observes DST, and without a param or a DB value, I'm not sure how that's going to be done. But the big issue is why Crystal doesnt support DST when converting from UTC.

Posted By: rkrowland
Date Posted: 29 Feb 2012 at 4:18am
Originally posted by turdferguson

It's more than just simple dateadd formulas. You have to check second sundays for both November and March.

Even moreso, you'll have to somehow check if its in an area that observes DST, and without a param or a DB value, I'm not sure how that's going to be done. But the big issue is why Crystal doesnt support DST when converting from UTC.
 
He only needs to do it for one timezone, and since he's making remarks towards DST I'd say it's safe to assume DST applies. The following formula should get people start at identifying DST periods and applying adjustments based on them.
 
@Formula
datetimevar datecheck;
datetimevar dststart;
datetimevar dstend; 


datecheck:= {table.datefield} 


dststart:= dateadd("d",8-dayofweek(date(year(datecheck),03,07)),date(year(datecheck),03,07)); 


dstend:= dateadd("d",8-dayofweek(date(year(datecheck),11,07)),date(year(datecheck),11,07)); 


if datecheck in dststart to dstend 


then "DST Period"
//then dateadd("h",3,datecheck) // +3 hours to {table.datefield} 


else "Not DST Period"
//else dateadd("h",2,datecheck) // +2 hours to {table.datefield}
 
Regards,
Ryan.

Posted By: turdferguson
Date Posted: 29 Feb 2012 at 4:23am
Originally posted by rkrowland

Originally posted by turdferguson

It's more than just simple dateadd formulas. You have to check second sundays for both November and March.

Even moreso, you'll have to somehow check if its in an area that observes DST, and without a param or a DB value, I'm not sure how that's going to be done. But the big issue is why Crystal doesnt support DST when converting from UTC.
 
He only needs to do it for one timezone, and since he's making remarks towards DST I'd say it's safe to assume DST applies. The following formula should get people start at identifying DST periods and applying adjustments based on them.
 
@Formula
datetimevar test;
datetimevar dststart;
datetimevar dstend;


 


test:= dateadd("yyyy",-1,currentdate()); // Change to date field...


 


dststart:= dateadd("d",8-dayofweek(date(year(test),03,08)),date(year(test),03,08));



dstend:= dateadd("d",8-dayofweek(date(year(test),11,08)),date(year(test),11,08));


 


if {table.datefield} in dststart to dstend



then "DST Period"
//then dateadd("h",3,{table.datefield})



else "Not DST Period"
//else dateadd("h",2,{table.datefield})
 
Regards,
Ryan.


The rest of his post goes on to say that "As more companies run global operations this will become more of a problem." Ours is global, thus why this is an issue.

But thanks for the formula. It's a bit different from how I started ours but much better, but one question. 

test:= dateadd("yyyy",-1,currentdate()); // Change to date field...

I dont quite understand what you're accomplishing here.

Posted By: rkrowland
Date Posted: 29 Feb 2012 at 4:25am
I did that to check my dststart and dstend formulas were working for last year aswell as this year - that var should just refer to the datefield in question. 
 
Regards,
Ryan.
 
EDIT: Note, the dststart and dstend formulas won't work for every scenario in the above example. My brain's a little fried at the minute but the following should work better;
 
dststart:= dateadd("d",8-dayofweek(date(year(test),03,07)),date(year(test),03,07));
dstend:= dateadd("d",8-dayofweek(date(year(test),11,07)),date(year(test),11,07));

Posted By: turdferguson
Date Posted: 29 Feb 2012 at 5:34am
Originally posted by rkrowland

I did that to check my dststart and dstend formulas were working for last year aswell as this year - that var should just refer to the datefield in question. 
 
Regards,
Ryan.
 
EDIT: Note, the dststart and dstend formulas won't work for every scenario in the above example. My brain's a little fried at the minute but the following should work better;
 
dststart:= dateadd("d",8-dayofweek(date(year(test),03,07)),date(year(test),03,07));
dstend:= dateadd("d",8-dayofweek(date(year(test),11,07)),date(year(test),11,07));


My brain isnt at 100% today... why are you subtracting 8-7 for the dateadd? It that finding the second sunday of the month somehow? Or can you explain it for poor little ol me?

Posted By: rkrowland
Date Posted: 29 Feb 2012 at 5:41am
I'll explain the dststart and hopefully you'll be able to figure out dstend from that :)
 
dateadd("d",8-dayofweek(date(year(test),03,07)),date(year(test),03,07))
 
date(year(test),03,07)) = perform calculations on date 07-March-year, we start with this date as the second Sunday within any month must fall between the 8th to the 14th.
 
The dayofweek part calculates what day of the week the 7th of march was in the corresponding year. ie if the 7th was a Monday, it would return 2.
 
From that we can work out what date the second Sunday in that month/year was.
 
The 8 - dayofweek is the number of days we need to add to the 7th of March to get to a Sunday. So let's go with our Monday example above 8-2 = 6, 6days + 7th = 13th. Which means the second Sunday in March that year fell on the 13th.
 
We do the same for November and check to see if our date falls between both of them.
 
Hope that helps.
 
Regards,
Ryan.

Posted By: turdferguson
Date Posted: 29 Feb 2012 at 5:49am
Interesting! I was thinking it straight up subtracted from the 03/07/year... and that you meant to mean 8+ instead of 8- dayofweek to get the second sunday...

Thanks Ryan!

Posted By: lockwelle
Date Posted: 29 Feb 2012 at 6:20am
ok, looked up daylight saving times in wikipedia...Ryan's solution won't work for every where.  Why, not every country starts / stops their DST on the same day.
 
And because of the friggin complexity that every country/state may use or not DST and that the start/end of DST varies between countries would be nightmare to code / maintain, especially since each country can change the date that the start/stop DST...
 
last note, according to Wikipedia, Australia ends DST the first Sunday in April...not starts on the 2nd Sunday of March...just another complication, since the southern hemisphere is the reverse of the northern...

Posted By: edmhess
Date Posted: 01 Mar 2012 at 4:36am

I'm going to use a subreport for my headers that has the date/time and use DateAdd("h", 16, CurrentDateTime) for Melbourne.  I want to replace the 16 with a system parameter that could be set by an admin whenever there are DST changes in PA or Melbourne.  I don't like it but I don't want the end-users to have to enter an offset every time they run a report.

It looks like the report is getting the Company Name with SystemParamCompanyName1 : ?SystemParam_Company_Name.  I can't find anything in the online help about system parameters and don't know how to set them up.
 
Thanks.

Posted By: turdferguson
Date Posted: 02 Mar 2012 at 10:38am
I've now run into a new problem with the function given to me.

We've been testing against EST -5:00GMT and PST -8:00GMT (if i got the acronyms wrong, whatever).

When we put the following through EST, we get an issue, and only on this specific case. Normal cases outside of dates residing alongside the DST change are fine.

1. On 3/11/2012, at 9:59:59AM UTC, it returns 4:59:59AM EST. This is correct, and outside DST so a five hour difference is correct. When converting to pacific time on my machine, we should see 1:59:59AM, since it's an eight hour difference. Instead, I get 12:59:59AM.


ShiftDateTime (testdate, ",0,UTC","")  //Convert to the user's current timezone.

datetimevar test;
datetimevar dststart;
datetimevar dstend;

test:= testdate;

dststart:= dateadd("d", 8 - dayofweek(date(year(test),03,07)), date(year(test),03,07));

dstend:= dateadd("d", 8 - dayofweek(date(year(test),11,07)), date(year(test),11,07));
 
if test in dststart to dstend
then dateadd("h",0,test)
else dateadd("h",1,test)

Posted By: rkrowland
Date Posted: 04 Mar 2012 at 11:38pm
Ok is that the 11th of March or the 3rd of November?
 
You'll have to forgive me, I hate the American date format haha! Common date format in England is dd/mm/yyyy - which just makes it confusing when looking at American dates! ;-) I always try to post dates in dd/mmm/yyyy when using forums with multiple nationalities just to make things easier!
 
I'm going to assume it's 11-Mar-2012 - if so the problems are most-definetely caused by the fact that 11-Mar-2012 is the startdate of our DST calculation - however I'm not entirely sure what's causing it as none of the time calculations decrease/increase the hours enough for it to be listed on 2 separate days.
 
Perhaps try applying our DST calculation after you've changed the defaul timezone hours. IE change
 
test:= testdate;
to
 
test:= ShiftDateTime (testdate, ",0,UTC","");
 
Again I'm not familiar with the shiftdatetime function and I'd probably find a way of using dateadd to do this part too, however if you're comfortable with it's functionality go nuts! ;-)
 
Regards,
Ryan.

Posted By: turdferguson
Date Posted: 05 Mar 2012 at 6:16am
^ fix doesnt work. the dates we're checking are march and november... the 7 is the number of days to add. Check the formula explanation on page 3.


Also having issues with PST when it comes to 11/4/2012. On EST, 8:59am -> 3:59am, and the finish time comes to 9:00am-4:00am.

Now on PST, we get 1:59:59am, and 1:00:00am.

Note this is 11/4, not 11/11.

I'm not sure at ALL why its doing this. the Dateadd returns ("d", 4.00, 3/7/2012), so we should get 3/11/2012. In fact, ALL runs of this function for 2012 should return 3/11/2012. So I'm not sure why 11/4 is doing this...

Posted By: turdferguson
Date Posted: 05 Mar 2012 at 10:57am
The big issue we are experiencing is that on these specific days, 11/4, 11/11, and 3/11, the DateTimeShift is mucking up hardcore on timezones outside of our own.

For example,

If I run a report with a RecId that has a date in December, lets say 12/17/2012, it will display the correct times with both equations.

If it happens to have a fringe date, such as both days that DST changes fall on, or for some reason, 11/4, then it blows up on timezones other than EST (Which is in my case, the timezone im actually in)

Posted By: rkrowland
Date Posted: 05 Mar 2012 at 10:22pm
Ok just to investigate this, create 2 new formulas, one containing just the dststart and the other the dstend.
 
Drag it in your data and make sure it is returning the correct dates for all records. From their we can investigate what's happening.
 
Also, you most definetely have to apply the timezone adjustment before checking the dst period as DST (or British Summer Time as it's known here) in GMT starts 8 hours before it would start in PST.
 
Also, you may need to make an adjustment for seconds on the dststart and dstend formulas as I'm pretty sure the clocks change at 23:59:59 on the second sunday, at the minute the formulas reference 00:00:00 on that sunday (almost a full 24 hours out).
 
Regards,
Ryan.

Posted By: turdferguson
Date Posted: 06 Mar 2012 at 4:13am
Originally posted by rkrowland

Ok just to investigate this, create 2 new formulas, one containing just the dststart and the other the dstend.
 
Drag it in your data and make sure it is returning the correct dates for all records. From their we can investigate what's happening.
 
Also, you most definetely have to apply the timezone adjustment before checking the dst period as DST (or British Summer Time as it's known here) in GMT starts 8 hours before it would start in PST.
 
Also, you may need to make an adjustment for seconds on the dststart and dstend formulas as I'm pretty sure the clocks change at 23:59:59 on the second sunday, at the minute the formulas reference 00:00:00 on that sunday (almost a full 24 hours out).
 
Regards,
Ryan.


I've done all of that. It's all the same data being returned.

but the last suggestion is interesting, but it doesnt help my problem.

my big current problem that i keep posting about is that the UTC to local conversion formula is giving me the wrong times on those days, with or without the DST formula.

Posted By: rkrowland
Date Posted: 06 Mar 2012 at 4:31am
Have you tried using dateadd to add/deduct hours for the timezone conversion rather than the dateshift function?
 
I have no idea how that function works, I'm fairly competent with complex dateadd/datediff formulas and pretty much any time calculation can be done with them so I never bothered learning anything else.
 
I can't really offer support on a function I don't understand myself. ;-)
 
Regards,
Ryan.

Posted By: turdferguson
Date Posted: 06 Mar 2012 at 4:36am
Originally posted by rkrowland

Have you tried using dateadd to add/deduct hours for the timezone conversion rather than the dateshift function?
 
I have no idea how that function works, I'm fairly competent with complex dateadd/datediff formulas and pretty much any time calculation can be done with them so I never bothered learning anything else.
 
I can't really offer support on a function I don't understand myself. ;-)
 
Regards,
Ryan.


by function you mean ShiftDateTime (fieldname, ",0,UTC", "")  ?

I cant use dateadd because we have many different customers in different timezones and they could also be running the report from a different timezone depending on each location. Coding each of our 25+ reports for each location anyone in the company might be is just ridiculous and out of the question,

so we need this function. It works for the most part and is all over google.

http://community.landesk.com/support/docs/DOC-11762

main topic.

Sorry Ryan :/

Posted By: rkrowland
Date Posted: 06 Mar 2012 at 5:24am
I've just read the function description, although PST isn't working for you (I'm assuming you enter the PST settings manually as it isn't your local timezone) I'm guessing it would for someone who's timezone is currently set to PST.
 
As you say it's working correctly for EST which is your local timezone?
 
Rather than testing in Crystal - perhaps try changing your Windows OS Timezone to PST?
 
Sorry I can't offer a more definitive solution but it's sort of the blind leading the blind at the minute haha!
 
Regards,
Ryan.

Posted By: turdferguson
Date Posted: 06 Mar 2012 at 7:16am
That is how I've been testing, by setting my timezone on the windows OS to different zones. Each one except EST is incorrect.

Posted By: rkrowland
Date Posted: 07 Mar 2012 at 2:39am

Well I think maybe to fix the 11-Mar-12 and the 11-Nov-12 issue we need to work from the second Monday, rather than the second Sunday.

It's has to be something with our calculation for it to be wrong on those specific dates. To change our formula to work for Monday instead of Sunday replace all of the following;

dayofweek(date)
 
with this;
 
dayofweek(date,crMonday)
 
As for the 11-Apr-12 I have no idea what could be causing that, try the above and let me know if it fixes the other 2 dates and we'll get to April after.
 
Regards,
Ryan.

Posted By: turdferguson
Date Posted: 08 Mar 2012 at 3:40am
Originally posted by rkrowland

Well I think maybe to fix the 11-Mar-12 and the 11-Nov-12 issue we need to work from the second Monday, rather than the second Sunday.

It's has to be something with our calculation for it to be wrong on those specific dates. To change our formula to work for Monday instead of Sunday replace all of the following;

dayofweek(date)
 
with this;
 
dayofweek(date,crMonday)
 
As for the 11-Apr-12 I have no idea what could be causing that, try the above and let me know if it fixes the other 2 dates and we'll get to April after.
 
Regards,
Ryan.


Again, its helpful, but the issue is I'm NOT using that formula and I'm getting bogus times. I'm just using the DateTimeShift on our UTC database value.

Posted By: arigatou
Date Posted: 18 Mar 2012 at 4:07pm
I understand that this is in your specifications, but you will need such a feature? I think if your EST or EDT value represents a place, do not use it to adjust.

-------------
http://www.meritline.com/hp-combo-hp96-hp97-ink-cartridges---p-19744.aspx - HP 97

Posted By: turdferguson
Date Posted: 19 Mar 2012 at 3:47am
Originally posted by arigatou

I understand that this is in your specifications, but you will need such a feature? I think if your EST or EDT value represents a place, do not use it to adjust.


....What??.... Are you actually suggesting, that having a report with incorrect times for paying customers isn't needed? I wouldn't be working on this for such a long time if it wasn't needed, nor would I have made a forum topic about it.

Posted By: rkrowland
Date Posted: 19 Mar 2012 at 4:38am
He's a spammer Turd! ;-)
 
He'll have copied a previous reply in the thread and reworded it in an attempt to get people to click on the link in his signature. :)
 
Regards,
Ryan.

Posted By: turdferguson
Date Posted: 19 Mar 2012 at 4:57am
Originally posted by rkrowland

He's a spammer Turd! ;-)
 
He'll have copied a previous reply in the thread and reworded it in an attempt to get people to click on the link in his signature. :)
 
Regards,
Ryan.


So I blew a gasket for nothing? :(

Posted By: turdferguson
Date Posted: 23 Mar 2012 at 11:04am
Still experiencing this issue. Namely the UTC conversion. :/ 

Posted By: turdferguson
Date Posted: 10 Apr 2012 at 9:26am
Giving it another bump. Havent had much time to flirt with the issue, but mostly because I dont know how to approach it.

So the  ShiftDateTime ({Table.Column}, ",0,GMT","")   , when I shift my computer from Eastern to Pacific Time Zone, will be off by up to two hours. I have no idea why.


Print Page | Close Window