I currently have a code that changes date to local time by adding 3h to current time.
=Format(DateAdd("h",3,Now()), "dd.MM.yyyy hh:mm:ss tt") & " EET"
This works fine now, but the problem is that i need to have daylight savings time also taken into consideration. This means that i need to have a "Select Case" -statement, where i would evaluate:
if the date is between 27.3.2022 and 27.9.2022 +3
if the date is between 28.9.2022 and 26.3.2023 +2
if the date is between 27.3.2023 and 27.9.2023 +3
if the date is between 28.9.2023 and 26.3.2024 +2
and so on....
How do i write this in vb script (used in Power BI report builder)?
Thanks for the help!
The expression language for paginated reports is VB.NET, so you can use the .NET docs to find the right expression to convert the current UTC time to local time an a particular time zone, eg:
= TimeZoneInfo.ConvertTimeFromUtc(DateTime.UtcNow, TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time"))
The problem with this solution is, that when I publish this to PowerBI Service, it uses the Power BI Service's default timezone, which can't be changed. Therefore the solution would need to be a static set of date-ranges which define the correct time zone despite having changes in the time due to daylight savings.
Related
I have a table storing a time value say "11:00 AM". This is what the client's would want the progress to run every day. The client also has a timezone info table letting me know which time zone its office is located. So "11:00 AM" in Eastern time zone is very different from "11:00 AM" in Pacific.
Then I have a program that checks whether the current time is what the client's desired runtime. This process runs in Eastern time zone always.
I am trying to figure out an easy way to compare whether my current time is actually the client's desired run time. What I am doing now is something like this:
Get the current DateTimeOffset of my environment. This will produce something like '2021-03-15 16:02:22.3112948 -04:00'
Then get the client's run time, which is "11:00 AM" or whatever the value, as well as client's timezone offset by using the sys.time_zone_info table. This give me the actual offset value, taking DST into consideration so that I don't have to calculate whether today is in DST or not.
I then construct a Datetimeoffset value from string by using current date value + client's run time value + the offset value. Then convert this into Eastern time zone using at time zone 'Eastern Standard Time'
By now, I have two values both in Eastern time zone and I can compare them. First question -- do you see any potential issue with my logic? Secondly, is there a better/easier way to do this?
Thanks!
I have a vb.net program, updating the time value in an access database. The database is connected using OleDB.
Basically this is what is happening:
Dim commandBuilder As New OleDb.OleDbCommandBuilder(dataEventAdapter)
eventDataset.Tables("EventList").Rows(selectedEvent)("EventTime") = Format(dateTimePick.Value, "hh:mm tt")
dataEventAdapter.Update(eventDataset, "EventList")
The time is taken from a datetime picker, and it should store only the time value.
The problem is, that the database already has values in it, which only has the time, like: 9:00 AM, but when I'm updating with this, it gets the date as well. And honestly I don't know where it gets the date from. If I
MsgBox(Format(dateTimePick.Value, "hh:mm tt"))
I get only the time, and nothing else.
How can I store the time only?
If you look at the datatypes available in MS-Access you will find that there isn't a type just for Time values but there is a type for Date/Time values. This means that Access will store always the date AND the time for the values that you supply. The display that you observe looking at the MS-Access grid is controlled by the Format setting in the structure page of your table and here you could change it to show just the Time part of your data.
Said that, there is the problem that you don't supply a DateTime value, but a string. Access is gracious(?) enough to not trigger an exception for this, but compensates adding a date by itself thus you should see the current day for every value that you supply.
So you shouldn't be concerned about how your value has been displayed, but more on how you pass that value to the database. If only the time part is meaningful for your program then leaving the database engine convert back your string to a datetime value is not an option. (Without talking about the localization issues that this automation will involve)
I suggest to pass a constant value for the Date part (like DateTime.MinValue or 1/1/1) and add your time to this value. In this way you could easily ignore the date part if you eventually need to use some queries on this data.
Dim dt As DateTime = new DateTime(1,1,1, dateTimePick.Value.Hour, _
dateTimePick.Value.Minute,
dateTimePick.Value.Second)
eventDataset.Tables("EventList").Rows(selectedEvent)("EventTime") = dt
You can make a simple experiment in Access. Open the Immediate window with Ctrl-G and enter
?Format(#00:00:00#,"yyyy/mm/dd hh:nn:ss")Enter
1899/12/30 00:00:00
?Format(#08:31:57#,"yyyy/mm/dd hh:nn:ss")Enter
1899/12/30 08:31:57
The result shows you the origin Access uses for its time axis.
Another experiment shows this:
?#1899/12/30 08:31:57#Enter
08:31:57
Access automatically displays only the time part for the date 1899/12/30.
Therefore I suggest to use this date as a base for time-only data.
Access uses Double values to store dates internally, where the integer part represents the number of days elapsed since 1899/12/30 and the decimal fraction represents the time as fraction of 24h (i.e. 0.25 is 06:00 am and 0.75 is 18:00).
?CDbl(#1899/12/30 08:00:00#)Enter
0.333333333333333
?CDbl(#1899/12/30#)Enter
0
?CDate(0)Enter
00:00:00
?CDate(0.25)Enter
06:00:00
In .NET you can use the System.DateTime.FromOADate(d As Double) As Date method for the conversion of Access Dates given as Double to .NET Dates (VB Date = System.DateTime).
You are confusing data types with formatting. In your database the column you are inserting into has a datetime datatype (Access has no data type for just time). This means that it stores everything that goes in there as a date + a time.
If in Access you are seeing values with only a time, it's likely that Access decided the date is useless (possibly because it was stored with a date of 1/1/1900).
Thing to remember is that the date still being stored. When you re-display the data just format it to only display the time. Judging from your code example you already know how to do that.
We use a program that saves the time-stamps in UTC time. We are a local to Utah company so we are affected by Daylight Savings time.
For example if we receive a call right now it is 12:52:00 MST and it would be saved in the database as 19:52:00.
My first concern is next year when DST starts again on March 13th 2016 and I run this at the exact same time. Will the time stamp in UTC be then 18:52:00 or would it stay at 19:52:00?
My second concern is if I convert the date in the database to my local time so I have to first check if it DST and then if it is take the time -6 and if not it would be -7?
So using the above example:
IsDST = 01:52:00 (-6)
IsNotDST = 12:52:00 (-7)
I assume this is something I need to worry about having to convert to/from UTC?
My main question aside from the two concerns above. Is there anything built into SQL Server/T-SQL that handles this conversion for me or do I need to write everything myself to take care of the need?
I have it started already, but now need to work in the DST if it is necessary
DECLARE #declared_start_datetime DATETIME,
#declared_end_datetime DATETIME,
#converted_start_datetime DATETIME,
#converted_end_datetime DATETIME
SET #declared_start_datetime = '11/04/2015 07:00:00' -- Hour we open phones
SET #declared_end_datetime = '11/04/2015 18:00:00' -- Hour we close phones
SET #converted_start_datetime = DATEADD(second, DATEDIFF(second, GETDATE(), GETUTCDATE()), #declared_start_datetime)
SET #converted_end_datetime = DATEADD(second, DATEDIFF(second, GETDATE(), GETUTCDATE()), #declared_end_datetime)
select #declared_start_datetime as 'Declared Start',
#declared_end_datetime as 'Declared End'
select #converted_start_datetime as 'Converted Start',
#converted_end_datetime as 'Converted End'
For example if we receive a call right now it is 12:52:00 MST and it would be saved in the database as 19:52:00.
My first concern is next year when DST starts again on March 13th 2016 and I run this at the exact same time. Will the time stamp in UTC be then 18:52:00 or would it stay at 19:52:00?
Mountain Standard Time is UTC-7, and US Mountain Daylight time is UTC-6. It's a lot easier to reason about if you write out the full date, time, and offset(s) involved in the conversion. Here it is in standard ISO8601 extended format:
2015-11-06T12:52:00-07:00 = 2015-11-06T19:52:00Z
2016-03-13T12:52:00-06:00 = 2016-03-13T18:52:00Z
Each local time on the left side of the equation is marked with the correct local time and local offset for that time. Then to get to UTC (identified by Z), you simply subtract the offset from the local time. Or, think of it as inverting the sign and adding, if that's easier to rationalize.
So yes, it would store it at 18:52:00 UTC when you are in daylight time. This is the correct behavior.
My second concern is if I convert the date in the database to my local time so I have to first check if it DST and then if it is take the time -6 and if not it would be -7?
Yes, but keep in mind that it's the date and time reflected by the timestamp you're converting. It makes no difference whether you are currently in DST or not.
However, keep in mind that time zone conversion should usually be avoided in the database layer, if you can all help it. In the vast majority of use cases, it's an application layer concern.
For example, if you're writing to SQL Server from an application built in .NET, then you could use the TimeZoneInfo class with the "Mountain Standard Time" ID (which is for both MST and MDT). Or, you could use the Noda Time library with the TZDB identifier of "America/Denver".
By using a library, you don't have to concern yourself with all of the various details of when DST starts and stops, nor how it has changed throughout history in different parts of the world.
In the rarer case where you actually need time zone conversion done at the database level, you can certainly write a stored procedure or UDF of your own (such as some of the question comments linked to), but depending on your needs they may not be sufficient. Typically they tend to encode just one set of fixed rules for time zone conversions, so they won't take other time zones or historical changes into account.
There are a few generic time zone solutions for SQL Server, but unlike other database platforms, there's nothing built in. I'll recommend my SQL Server Time Zone Support OSS project, and there are others if you search. But really, you should hopefully not need this, and should do the conversion in the application layer whenever possible.
Update: With SQL Server 2016 CTP 3.1, there is now built-in support for time zones via the AT TIME ZONE statement. See the CTP announcement for examples.
I am developing reports using Microsoft SQL Report Builder 2.0. One of my requirement is to display the timezone information by passing "Timezone Offset" (-08:00) as a parameter to the report. Based on the offset value, we convert a UTC date to its appropriate timezone value (using VB.NET) and display the same. However, this does not consider the daylight savings. Is there anyway to incorporate daylight savings related changes to our conversion?
FYI, the platform is .NET Framework 3.
Thanks,
Veera
Take a look at the following:
TimeZone.GetDaylightChanges
DaylightTime
TimeZoneInfo
There are all sorts of properties and methods that you may be able to take advantage of.
I got the answer, If I want to acce.ss the timezone in the code. I need to add the "system.core" & then if imezonecreate a timezoninfo object and I can create custom timezone. Also we can get all timezones available zones from the system.
http://msdn.microsoft.com/en-us/library/system.timezoneinfo_members(v=VS.100).aspx
http://msdn.microsoft.com/en-us/library/bb309898(v=VS.100).aspx
I posted a question a couple of days ago (SQL Reporting Services Daylight saving time query) which was I received an answer for (thanks very much) but did not elaborate on the whole problem I am experiencing. Not only did I require the returned date time format to account for day light saving but I also need the search parameter #StartDate to allow for DST.
Currently if I key in a scheduled start time of 31/03/2010 11:00 and because the SQL DB has already taken the hours difference into consideration I get no results back. If I key in 31/03/2010 10:00 then the correct details are returned. Is there away using T-SQL or the like to get the search parameter to pass the adjusted time to the DB?
SQL Server 2008 supports the data type "TIMESTAMP WITH TIMEZONE". Might be worth a try.
You can download a 180-day trial version.
In any case, the timezone for an appointment application is what I'd call critical business information. I'd store it in the database, by one of these methods:
using the right data type
building a user-defined data type
adding a column for time zone info