I use InfluxDB as Datasource and Flux as query language.
In the time format the displayed value is e.g. 2023-02-10 16:47:33. When using toString() I get 2023-02-10T15:47:33.9000000000Z. So the value changes by one hour.
I tried different time zones settings but nothing changed.
The value-change does not appear when querying directly in Influx.
Related
How to use to_date function in oracle-sqldeveloper to convert a string
May 1 2019 12:00 to date datatype? Does Date in SQL store time too,
or it only stores date? I tried using the to_date function with some
format but it always removes the time part.
If the time is not possible in Date datatype what could be a good alternative?
You can convert your date to a string with (assuming 24-hour values, which seems likely as you don't have an AM/PM marker):
to_date('May 1 2019 12:00', 'Mon DD YYYY HH24:MI', 'nls_date_language=English')
The format elements are in the documentation. I've included the optional third argument to to_date() because your month name has to be interpreted in English, regardless of your session settings.
it always removes the time part
Oracle dates always have both date and time parts, even if the time is set to midnight. You're probably seeing the result of that query as '01-MAY-19'.
Dates don't have any intrinsic human-readable format; Oracle uses its own internal representation, which you generally don't need to worry about.
In most clients and IDEs the session NLS_DATE_FORMAT setting is used to display native dates as strings. For historic reasons that still defaults to DD-MON-YY, despite Y2K, during database creation. it can be changed at database level, and sessions will then inherit that. But each session can override it, e.g. by issuing:
alter session set nls_date_format = 'YYYY-MM-DD HH24:MI:SS'
You can also explicitly convert a date value back to a string, and specify which format elements you want to include, via a to_char() call. Only do that when displaying a value - if you're storing dates or passing them around to functions, always do that as the proper date data type, not as strings. (If you have to pass them outside the database as strings, e.g. to a remote API, you'd usually want to use an ISO-8601 format).
db<>fiddle showing the default output, explicitly formatted as a string (again, for display only - do not store or manipulate dates as string), and with the session format modified.
In SQL Developer you can also go to Tools->Preferences->Database->NLS and change the 'Date format' there - that setting will then apply when you create new sessions, without having to issue alter session each time.
I have a:
Field in my store as date with dateFormat set to 'Y-m-d'
Column in my grid (datecolumn) - format set to 'Y-m-d'
Editor on Column (datefield editor) - format set to 'Y-m-d'
Postgresql Table with a date column (Note, not a timestamp or timestamptz, but date)
I have data that comes into the store from Postgresql like:
{
mydatefield: "2021-07-30"
}
Now, the date do dispay is 100% correct in the grid. Problem comes in when I select a new date, through the datefield editor, let's say
2021-07-31
The moment it saves back to the server it passes:
mydatefield: '2021-07-30T22:00:00.000Z'
and the server saves it wrong as '2021-07-30' and the grid refreshes back to 2021-07-30.
We are on South African Standard Time (+2) Do not know if it something to do with Daylight Saving
So, to recap. It does not matter what date I select, it keeps saving a day less than the day I selected.
The date it's saving is in UTC, which is the timezone you ought to be using on your server(s) and database(s) - that's a good thing as it removes timezone related info and allows dates to be localized to any timezone.
When you transmit date values over the wire between the server and the browser, make sure you're using RFC-8701 formatted strings (what you get when you call new Date().toJSON() in JavaScript). Then you won't have to worry about timezone issues, as RFC-8701 dates are always in UTC. The browser will take care of transforming dates to local time - just call new Date(myRfcDateString).
More info: Storing date/times as UTC in database
Use convert method of store to process data for date column before storing it in store data. Then the store data will be submitted to server in proper format.
There was similar question asked, links below -
Question - Datefield in grid editor
Fiddle - https://fiddle.sencha.com/#view/editor&fiddle/2e0a
I have an app that creates some entities (it doesn't really matter for this question), but the entities could be created in different timezones, so I have to store UTC offset in my createdAt and updatedAt columns. For some reasons, I'm not able to save generated date correctly, please refer to the code snippet below, to get more details:
Here is what I'm doing:
const { user } = userInfoWebAPICallResult as WebAPICallResult
const now = moment(moment.now())
.tz(user.tz!)
.toDate();
const entity = await Entity.create({
...someData,
createdAt: now
updatedAt: now,
});
I'm getting tz value externally, it's a string which looks like "America/Los_Angeles". If I convert now to string (by calling .format() method) and log the received value I will see something like this "2020-01-03T16:32:53-08:00". As you can see the date has offset value, this is the correct date, but during inspecting the Database I see "2020-01-04 00:32:53.013 00", this string doesn't have offset value anymore and it looks like the resulting date was computed automatically.
I will need to implement the filtration by createdAt date, people from different timezone will use this filtering mechanism. I planned to expose two parameters date and utcOffset via API, which would allow me to return correct entries depending on the user time zone.
What I'm missing?
The moment when the entity was created / updated should probably be stored in UTC; it is a timestamp that identifies an exact point in time when the event happened.
I would suggest dealing with time zones on the output part: convert a UTC timestamp to a display that takes the user's time zone into account.
If you need to know what time of day it was for the user who created or updated the entity, I would store that user's time zone in a separate column, using standard time zone identifiers (like "America/New_York" rather than "EDT" or "EST").
I have a library with custom content type with .docx template.
I have a 'StartDate' and 'EndDate' fields in the content type which are mapped to quick parts in .docx template.
When I change the values of these two fields in item properties, it updates the values in document as well (as it's supposed to be).
PROBLEM
The values in the document are always one day off.
If for example I set the date to 15/04/2016, it shows 14/04/2016 on the document.
How can I make them equal?
The time zones and everything seems to be fine on SharePoint and on my local machine.
I believe this issue is being caused by the way SharePoint stores date and time values. From the SharePoint MSDN article on Converting Date and Time Values:
Microsoft SharePoint Foundation stores date and time values in Coordinated Universal Time (UTC) format, and almost all date and time values that are returned by members of the object model are in UTC format.
So when you enter a date and time into SharePoint in local time, SharePoint stores that information in Coordinated Universal Time (UTC). But when the mapped content control in Word retrieves the date/time value it receives the UTC equivalent of whatever your local date and time is (SharePoint itself automatically converts date and time values to your local time when displaying that information within its own user interface).
I think the best way to solve this would be to create calculated fields that are not displayed. The calculated fields would take the input date/time values from your 'StartDate' and 'EndDate' fields in the content type and correct them for your local UTC offset. You could then map the corrected calculated values to Quick Parts in your Word document.
I have a table that I am using to store iso dates with timezones. I realize that dates should "always" be stored as utc but I have an exception to that rule. The timestamps aren't in any way related to the server they are running on. I want to be able to store an iso date like this:
2016-03-06T01:15:52-06:00
And regardless of the time zone of the server or anything else I want the timestamp returned as:
2016-03-06T01:15:52-06:00
Currently if I insert an iso date it automatically converts it to whatever the server timezone is. My above date gets converted to:
2016-03-06 07:15:52+00 (server is utc)
The only thing I can think of is storing the timezone offset in a separate column, storing my date as utc and then converting using the offset column, horribly messy. Surely there is a way to store my date in one column and get it out the way it was originally created?
Your proposed solution is correct. Or more precisely, it is one of several correct implementations. Any of the following would work:
Store the UTC timestamp in one field, store the offset in another.
Store the local timestamp in one field, store the offset in another.
Store the local date in one field, and store a time with time zone in another. (though time with time zone is generally discouraged...)
Store the UTC timestamps in one field and the local timestamp in another.
The easiest by far is the first one, which you already proposed.
I'd avoid against storing timestamps in text fields, as they tend not to be very efficiently searchable.
Also note - if you're coming from a SQL Server background, you might recall its datetimeoffset type, which stores the local datetime and offset in the field, and uses the UTC equivalent during indexing. It's common to think that Postgres and MySQL's timestamp with time zone would have the same behavior, but they don't. They simply use the session time zone to convert to/from UTC. SQL Server has no concept of a session time zone, and thus the discrepancy.
Be sure to read this part of the Postgres docs.