I have already calculated UTC (the datetime is set to be equal to the current UTC time) for a datetime property on my entity. I write it to CosmosDB, and I see in the DataExplorer that Microsoft has changed the datetime, doing a time conversion that puts it into the ALMT (Almaty, Kazakhstan) timezone. Why?
Does anyone know of any settings that can be turned off to prevent this from happening?
As far as the TableEntity TimeStamp property, it is set to be +00:00, using my datetime property.
Once it has been written to CosmosDB, it's been changed all the way from 09:43 PM July 10th to 03:43 AM July 11th, or ALMT timezone.
Do this to your DateTime properties before writing them to CosmosDB, or it will convert them from whatever your local timezone (still not sure how exactly / based on what it infers that) to Utc (and if you've created the DateTime with DateTime.UtcNow, then the resulting datetime after CosmosDB converts it will be wrong):
DateTime UTCDateTime = DateTime.SpecifyKind(DateTime.UtcNow, DateTimeKind.Utc);
After you set up your date time properties in your entity as such, no further date conversions will occur.
Related
As part of setting GCP project level timezone to AEST, I have run the following command -
ALTER PROJECT `gcp-abc-def`
SET OPTIONS ( `region-us.default_time_zone` = 'Australia/Sydney')
Doing so, I see that current_datetime() is getting changed to AEST whereas timestamp remains UTC, as can be seen below.
Can someone help how this can be remedied? What other settings to be changed?
I see that current_datetime() is getting changed to AEST whereas timestamp remains UTC this is because the current_timestamp function shows time in timestamp type. A timestamp does not have a time zone; it represents the same instant in time globally. When querying for CURRENT_TIMESTAMP() it shows explicitly in UTC by having zero time zone offset. When you convert a timestamp to some other type that isn't tied to a particular timezone, you can specify the timezone for the conversion.You can use format_timestamp to convert the timestamp into your zone specific time.
Example:
ALTER PROJECT `gcp-abc-def`
SET OPTIONS ( `region-us.default_time_zone` = 'Australia/Sydney');
select current_datetime() as cdt, current_timestamp() as cts,format_timestamp('%c',current_timestamp(),'Australia/Sydney') as cts2
I am creating OpenApi Doc for an API.
Having a model object field with DateTime info with timezone.
Example: "2021-12-30T10:00:00+00:00"
The expected input date should be in UTC.
If I use the format: "date-time" then the corresponding generated example is "2021-12-30T10:00:00.123z" where timezone information is missing.
Please suggest the right format to use in the OpenApi spec so that I can get the desired DateTime with a timezone value.
"2021-12-30T10:00:00.123z" ends with a 'z'.
This means this DateTime represents UTC time.
z stands for Zulu Timezone
UTC is sometimes known as "Zulu time"
I'm trying to convert a string datetime, to a timestamp. try_to_timestamp isn't converting dates in the yyyy-mm-dd hh:mm:ss AM/PM format. I've only been able to solve this by striping out the time and casting it as a type time and concatenating it back with the date. Anyone know of a Snowflake function to handle this?
select try_to_timestamp('2019-11-18 4:01:29 PM +0000')
your timestamp doesn't quite fit the ISO or RTC formats so it's not automatically detecting it. You can manually put in your format though. Should look something like this:
select to_timestamp('2019-11-18 4:01:29 PM +0000', 'YYYY-MM-DD HH12:MI:SS AM TZHTZM')
For information on the various formats SnowFlake uses: https://docs.snowflake.net/manuals/user-guide/date-time-input-output.html
EDIT:
You may or may not want to cast it as a timestamp_tz (timestamp with timezone) to maintain timezone information
select to_timestamp_tz('2019-11-18 4:01:29 PM +0200', 'YYYY-MM-DD HH12:MI:SS AM TZHTZM');
Since try_to_timestamp does not support a format, you can set it before calling the
try_to_timestamp function. The example below is setting it at the session level.
alter session set TIMESTAMP_INPUT_FORMAT = 'YYYY-MM-DD HH12:MI:SS AM TZHTZM';
select try_to_timestamp('2019-11-18 4:01:29 PM +0000');
I have a DateTime in my .NET program that I need to print with particular value of time zone offset (for instance, +01:00 always). Output should contain full date time with timezone. It has to be unrelated to system timezone setting. How I could achieve this?
Example: I have a timestamp such as 12-03-2016T12:30:34+03:00 and I need to output it calculated for predefined TZ +1: 12-03-2016T10:30:34+01:00
Found some approach to it.
First of all, DateTime does not have time zone stored in it. Instead it has flag whether it is UTC or Local (without the idea what Local TZ shift is). So: first thing is to get your initial parsing of time from any string time stamp in UTC.
Once it is stored in DateTime object (with Kind=UTC), you have to convert it to the timezone you desire output for. I find examples here useful: datetime to string with time zone.
Note: if you need to convert London daylight-saving time, you have to know right names of timezones in NET so you get it right. See Difference between UTC and GMT Standard Time in .NET
I am coding a MVC 5 internet application that is being deployed to an Azure website. This application is going to be used internationally, and I am wanting to know if storing any DateTime values should use UTC time?
Here is an example: I have an object that has a start date time value as well as an end date time value. These values are set by a user and are used to determine if data should be shown to a user. If the current date time value is between the start date time and end date time, then data is shown.
Because my application is going to be used internationally, and there are different time zones, should I store the start date time value and end date time value as a DateTime object with UTC, or a standard DateTime value would be all that is needed? Do I need to worry about setting and displaying DateTime values for different time zones, or is this incorporated into the DateTime object?
Thanks in advance.
EDIT
How about when editing a DateTime that is stored as UTC.
If I have a DateTime that is stored as UTC in an object, and the user wants to change this value, do I need to convert the DateTime (that is displayed as .ToLocalTime()) back to a UTC DateTime when I store this value back in the database after it has been edited?
EDIT2
Can you have a quick look at these functions that I have coded to ensure the coding is correct?
public DateTime ConvertUTCDateTimeToLocalTime(DateTime utcDateTime)
{
DateTime convertedDate = DateTime.SpecifyKind(utcDateTime, DateTimeKind.Utc);
return convertedDate.ToLocalTime();
}
public DateTime ConvertLocalDateTimeToUniversalTime(DateTime localDateTime)
{
DateTime convertedDate = DateTime.SpecifyKind(localDateTime, DateTimeKind.Local);
return convertedDate.ToUniversalTime();
}
public DateTime ConvertUTCDateTimeToLocalTime(string utcDateTime)
{
DateTime convertedDate = DateTime.SpecifyKind(DateTime.Parse(utcDateTime.ToString()), DateTimeKind.Utc);
return convertedDate.ToLocalTime();
}
public DateTime ConvertLocalDateTimeToUniversalTime(string localDateTime)
{
DateTime convertedDate = DateTime.SpecifyKind(DateTime.Parse(localDateTime.ToString()), DateTimeKind.Local);
return convertedDate.ToUniversalTime();
}
In general, you should prefer to use DateTime.UtcNow in your backend. First advantage is that you don't have to care about timezones and second, you don't have to do any calculations for Daylight Saving Times (read more in this article). .NET gives you great capabilities where you don't have to care much about the two points mentioned above. On the other side, you should never display the UTC time in your frontend. This can annoy your users, but here come the capabilities of .NET into play. If you have an UTC date you can easily convert it local time for displaying it to your user in the following way:
DateTime convertedDate = DateTime.SpecifyKind(
DateTime.Parse(dateStr),
DateTimeKind.Utc);
DateTime dt = convertedDate.ToLocalTime();
The snippet is taken from Drew Noakes answer on this thread, which is a great discussion about how you can convert your dates to local time.
EDIT
Regarding your edit: Yes, you have to do this. Otherwise the date will be stored in local time.