locked
SSRS Subscriptions created with wrong times RRS feed

  • Question

  • Hello,

    We host several TFS server on a single physical machine. The SQL servers (data tiers) are all hosted on the bare metal while the application tiers are virtualized. We are in the Eastern time zone and so are some of our clients, thus the physical host is set to Eastern time. We have a client in the UK whose time is offset by 4 or 5 hours (depending on Daylight Saving Time). Their application server is set to GMT.

    The problem is that when they create SSRS subscriptions, they do so in GMT (which is the correct timezone for all of their TFS). However, SSRS creates the schedule in EDT. For example, say they want a report emailed to them at the end of the say, at 1700GMT, they schedule is accordingly. However, the job gets created as 1700EDT, which means that they receieve the email at 2100GMT, four hours later than they need it.

    I can't imagine that this is expected behavior--IS it? The only solution I can think of is to move the RS dbs to the application tier. However, this doesn't comply with our practices (which I don't believe are particularly strange or unique) and would require more resources to be allotted to the application tier, which would, in turn, increase the price to our client. Another undesirable workaround would be to tell our client to convert the time for each of their subscriptions to our local time zone.

    So, is this a bug? If so, is there an ETA on a fix? If not, is there a workaround (other than forcing client to either pay for more resources to move RS to app tier, or creating subscriptions in a foreign time zone)

    Thank you


    P.S. here are the versions

    Windows Server 2008 R2 (on all servers involved)

    SQL Server 2012 SP1 with update rollup (SQL, RS, and AS [hosted on app tier])

    Team Foundation Server 2012 with Update 1



    • Edited by Reza Etezal Wednesday, March 13, 2013 10:16 PM
    • Moved by John Qiao Friday, March 15, 2013 8:02 AM
    Wednesday, March 13, 2013 9:15 PM

All replies