I need a SQL Server function (or composition) to record the UTC date and time with the timezone offset into one of my columns of type datetimeoffset(7).
I observe that the SYSUTCDATETIME function gets the UTC date and time into a datetime2(7) data type and therefore that doesn't store the offset.
So, my question is: is there a composition of functions that will yield a datetimeoffset(7) value with the UTC date time along with the time offset (0:00)?
Related
I felt like this should be easy but I'm not finding answer. The query below will give me the current date/time in California and represent it as UTC with a timezone offset (currently -08:00):
select getdate() at time zone 'Pacific Standard Time'
I simply want to apply the offset and get a timestamp showing the current local time and then drop the offset. I feel like there should be a way to achieve this without having to pick through it with string and date functions. For example, I want to go from
2021-11-24 18:03:41.190 -08:00
to
2021-11-24 10:03:41.190
Is there a succinct way to do this?
When you use AT TIME ZONE on a value that isn't a datetimeoffset it's assumed that the value is at the time zone you are converting it to.
Instead, therefore, you could nest the AT TIME ZONE clauses. If you did do this though, I would also suggest using SYSUTCDATE rather than GETDATE (which returns the local time to the host, which could be any timezone).
SELECT SYSUTCDATETIME() AT TIME ZONE 'UTC' AT TIME ZONE 'Pacific Standard Time';
Though really, just use SYSDATETIMEOFFSET to start with; then you just need one AT TIME ZONE as the RDBMS already knows what timezone the value is for.
SELECT SYSDATETIMEOFFSET() AT TIME ZONE 'Pacific Standard Time';
db<>fiddle
Declare #myDateTime datetime = '2021-11-24 21:35:25.984'; --UTC time
Select cast(#myDateTime At Time Zone 'UTC' At Time Zone 'Pacific Standard Time' As datetime);
Or - you can just apply the desired offset and convert back to datetime
Select cast(switchoffset(#myDateTime, '-08:00') As datetime)
The problem with using switchoffset is that it isn't DST aware and would need to be changed to use a different offset value. If you change the date above to October - the PST time would be 14:35:25.983 but the second calculation still returns 13:35:25.983
We have a SQL database that returns all the times in Greenwich Mean Time (GMT). We are in the Eastern Standard Timezone (EST). This messes up some queries that we have that pull data from specific dates. I tried using the (StartTime AT TIME ZONE 'Eastern Standard Time' as StartTime_ET, but that only returns the result as same in GMT -5. I just want the exact result to be in EST .
This changes the complete logic process of mine. Is there any way to do that?
Assuming your values are all UTC and that your column StartTime is not a datetimeoffset, then you need to turn your value into a datetimeoffset first, and then change the time zone. When you use AT TIMEZONE on a date and time data type that isn't a DATETIMEOFFSET it is assumed that the value is already at the correct timezone. Therefore, for example something like SELECT GETUTCDATE() AT TIME ZONE 'Eastern Standard Time'; would return 2021-08-05 09:53:56.8500000 -04:00 right now, even though the time in EST is actually 2021-08-05 05:53:56.8500000 -04:00 right now.
As a result you need to add the offset first and then use AT TIME ZONE. So, with GETUTCDATE that would be like this:
SELECT SWITCHOFFSET(GETUTCDATE(),0) AT TIME ZONE 'Eastern Standard Time';
Therefore, presumably, you just need to do the same for your column, StartTime, which is also a UTC time:
SWITCHOFFSET(StartTime,0) AT TIME ZONE 'Eastern Standard Time'
If you don't want the timezone portion, then you can convert it back to a different date and time data type:
CONVERT(datetime2(0),SWITCHOFFSET(StartTime,0) AT TIME ZONE 'Eastern Standard Time')
I have the following script giving me:
Select ENDTIME_UTC AT TIME ZONE 'E. South America Standard Time' as TransactionDate_ESAST
,ENDTIME_UTC as TransactionDate
From Table_CYC
--Results: 2019-11-09 21:02:28.000 -03:00, 2019-11-09 21:02:28.000
However, I would want it either -3 (as an integer for just the offset portion) or 2019-11-09 18:02:28.000, where the hour is subtracted by three.
What would be the best way to go about this?
Thanks,
Yolanda
As currently written you are asserting that the existing value is in Brasilia time and not performing any time zone conversion. Instead, you need to assert that the existing value is in UTC and then convert to Brasilia time.
This is done by calling AT TIME ZONE twice.
SELECT ENDTIME_UTC AT TIME ZONE 'UTC' AT TIME ZONE 'E. South America Standard Time'
The first AT TIME ZONE creates a datetimeoffset from your input datetime asserting that it should be applied with the UTC time zone.
The second AT TIME ZONE then converts from that datetimeoffset to another datetimeoffset with the given time zone.
Note that this is only necessary because your original field is of type datetime (or datetime2, etc.). If instead your field was a datetimeoffset, then your original code would work fine.
In my query I need to return only those records that are greater than another date, returned by the function. The field I am comparing is a timestamp and the date function returns is a of type DATE.
My query:
SELECT * FROM TABLE1
WHERE MY_TIMESTAMP > MyFunction1('Test Date');
when I am comparing two values where only time differs slightly - in munutes or seconds, the comparison does not work.
For example when
MY_TIMESTAMP=11/27/2018 12:15:42.000000 PM -05:00
and
MyFunction1('Test Date') returns 11/27/2018 12:22:00 PM
no record should be returned from TABLE1 for that ID but the record does get returned. What can I do to make the comparison more granular?
From Datetime and Interval Arithmetic
Oracle Database performs all timestamp arithmetic in UTC time. For
TIMESTAMP WITH LOCAL TIME ZONE data, Oracle Database converts the
datetime value from the database time zone to UTC and converts back to
the database time zone after performing the arithmetic. For TIMESTAMP WITH TIME ZONE data, the datetime value is always in UTC, so no
conversion is necessary.
If you provide a DATE or TIMESTAMP value (i.e. value without any time zone information) then Oracle attaches the SESSIONTIMEZONE to this value and then it does the comparison based on UTC.
Attaching SESSIONTIMEZONE to input value might be correct or not, it depends on your current session and content of MyFunction1
I want to create a table in redshift that stores incrementally incoming data from the source. The date field in the mysql source is not stored as UTC. Is it possible to convert and store the new record as UTC upon record creation.
I was thinking doing something like that:
CREATE TABLE test(
my_dt_field datetime without timezone NOT NULL ...)
Any help would be very appreciated!
Redshift provides following options of datatypes available to store dates:
1.DATE
Use the DATE data type to store simple calendar dates without time stamps.
2.TIMESTAMP
TIMESTAMP is an alias of TIMESTAMP WITHOUT TIME ZONE.
Use the TIMESTAMP data type to store complete timestamp values that include the date and the time of day.
TIMESTAMP columns store values with up to a maximum of 6 digits of precision for fractional seconds.
If you insert a date into a TIMESTAMP column, or a date with a partial time stamp value, the value is implicitly converted into a full time stamp value with default values (00) for missing hours, minutes, and seconds. Time zone values in input strings are ignored.
By default, TIMESTAMP values are Coordinated Universal Time (UTC) in both user tables and Amazon Redshift system tables.
3.TIMESTAMPTZ
TIMESTAMPTZ is an alias of TIMESTAMP WITH TIME ZONE.
Use the TIMESTAMPTZ data type to input complete time stamp values that include the date, the time of day, and a time zone. When an input value includes a time zone, Amazon Redshift uses the time zone to convert the value to Coordinated Universal Time (UTC) and stores the UTC value.
To view a list of supported time zone names, execute the following command.
select pg_timezone_names();
To answer your question declare your column datatype as TIMESTAMP, by default it stores in UTC
You can also refer AWS document here: https://docs.aws.amazon.com/redshift/latest/dg/r_Datetime_types.html