Edit
Opensearch increases the timestamp of the logs by one hour. It must somehow assume that the logs come from the UTC time zone. How do I change this behaviour?
2023-02-02 12:47:27,897 [INFO]: <log> becomes 2023-02-02 13:47:27,897 [INFO]: <log>
From the official documentation:
Internally, dates are converted to UTC (if the time-zone is specified)
and stored as a long number representing milliseconds-since-the-epoch.
Reference: https://www.elastic.co/guide/en/elasticsearch/reference/current/date.html
You can't change this behavior, but when you search the data you will see the correct time according to your browser time. Or you can specify the time zone during the search. For example:
GET _search
{
"query": {
"range": {
"timestamp": {
"gte": "2023-02-02 12:47:27",
"format": "yyyy-MM-dd HH:mm:ss",
"time_zone": "+01:00"
}
}
}
}
Related
The default output format of ngx-bootstrap datepicker is not ISO format as documented.
I would welcome this format but the actual format that I get is:
Sun Aug 02 2020 19:17:00 GMT-0400 (Eastern Daylight Time)
Stackblitz Example
I know there are ways to post process the format but this format seems weird for a default output format. Does anyone have experience with this?
In vanilla JavaScript there is a 'Date' object, the default output of which gives you the line you are seeing:
Sun Aug 02 2020 19:17:00 GMT-0400 (Eastern Daylight Time)
In physical memory, your Date object is actually being stored as the number of milliseconds since "January 1, 1970, 00:00:00" which using our above line is actually "1596410220000" milliseconds.
You can read the full specifications for the 'Date' object here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Numbers_and_dates
Meanwhile, to answer your question more specifically, your date picker is not giving the output you listed but instead applying its date to a 'Date' object (newDate). You are then setting another 'Date' object (updatedDate) to be equal to the Date object assigned by your date-picker (newDate).
This is done here:
onValueChange(newDate: Date) {
this.updatedDate = newDate;
}
So in memory your updatedDate is now represented as "1596410220000" milliseconds. When you output that 'Date' object to your HTML your browser is going to use the default output for the 'Date' object, giving you:
Sun Aug 02 2020 19:17:00 GMT-0400 (Eastern Daylight Time)
So there are two solutions that you can use if you want to get that Date into a different format.
First you can call a method on your newDate to return a different formatted string. For example, if we wanted to output it as the ISO string that you were looking for originally we change this:
export class AppComponent implements OnInit {
myDateValue: Date;
updatedDate: Date;
ngOnInit() {
this.myDateValue = new Date();
}
onValueChange(newDate: Date) {
this.updatedDate = newDate;
}
To this:
export class AppComponent implements OnInit {
myDateValue: Date;
updatedDate: String;
ngOnInit() {
this.myDateValue = new Date();
}
onValueChange(newDate: Date) {
this.updatedDate = newDate.toISOString();
}
First we changed "updatedDate" to be a string object and we called the method "toISOString()" on our "newDate" (which is the Date returned from our date-picker). This gives us the ISO formatted string, which for our example is:
2020-08-02T23:17:00.000Z
The other option is to simply apply formatting to your date in your angular DatePipe. For example, if we change this:
</div>
Updated Date: {{updatedDate}}
</div>
To this:
</div>
Updated Date: {{updatedDate | date:"shortTime"}}
</div>
We would be applying the shortTime format which is "h:mm a" or for our example:
7:17 PM
You can read the full list of angular date formats here: https://angular.io/api/common/DatePipe
To summarize:
Vanilla JavaScript (not angular or ngx-bootstrap) is controlling the output format for the "Date" object here. While the output looks weird, the variable itself is not stored in that format but in milliseconds (UNIX epoch time). You can call methods on a Date object to get various formats (including ISO, UTC, etc) or you can format from angular by passing a format command along the datepipe.
I have created an Azure Data Factory which has the following activity JSON as viewed in the portal (excerpt)
"start": "2018-07-27T00:00:00Z",
"end": "2099-12-30T13:00:00Z",
"isPaused": false,
"runtimeInfo": {
"deploymentTime": "2020-06-08T12:42:21.2801494Z",
"activePeriodSetTime": "2020-06-08T12:23:16.2436361Z",
"pipelineState": "Running",
"activityPeriods": {
"copyXZActivity": {
"start": "2017-06-27T00:00:00Z",
"end": "2099-12-30T13:00:00Z"
}
}
},
"id": "ef896997-2046-4b2e-7074-ecb5f58dd489",
"provisioningState": "Succeeded",
"hubName": "sxdb_hub",
"pipelineMode": "Scheduled"
My AzureSQLTable inputs and outputs have the following JSON config:
"availability": {
"frequency": "Minute",
"interval": 15
},
I would expect it to run immediately, every 15 minutes, but the activity window is empty. The next scheduled run at 5/3/2020, 4:30 PM UTC according to the activity window, which seems to be a random date in the past.
How do I get the activity to run, as expected, every 15 minutes?
The problem seems to have been this line, which caused execution to begin on 3 May 2020:
"copyXZActivity": {
"start": "2017-06-27T00:00:00Z",
Changing it to this fixed the issue:
"copyXZActivity": {
"start": "2020-06-10T00:00:00Z",
Changing the start date to the current date got the activity running. It appears like Data Factory 1, when given a start date in the distant past, chooses another date a few months ago, and starts executing the activity from that day, continuously, until it "catches up" and then follows the interval pattern (although I wasn't able to navigate via the monitoring UI to that date).
It exhibits this "catch up" behavior with any start date/time in the past.
I have to be doing something wrong but I cannot figure out what it is. I currently have a date field in my application that has a value format of MMMM, D YYYY.
For this example, I am going to be using the date October 1, 2018.
In the application, the user selects October 1, 2018 which logs as
October 1, 2018
Later I convert this date into a savable date by using var docDate = new Date($('#insuranceExpiration').val()).toISOString(); which logs as
2018-10-01T04:00:00.000Z
I then add this to an object stringify it and send it to the server where I log the date and shows as
2018-10-01T04:00:00.000Z
I then use Mongoose to save this date to MongoDB but when I go to see the saved date I show
2018-09-30T04:00:00.000Z
I cannot figure out for the life of me why I am seeing a date 24 hours in the past from the date I choose. Below is the mongoose code to see if I am doing something wrong on that end.
app.post('/api/myDocuments/insuranceGeneral', function(req, res ) {
console.log(req.body.expires);
// prints 2018-10-01T04:00:00.000Z
InsuranceGeneral.findOneAndUpdate({
_id: req.rsaConPortal.id
}, {
$set: {
"documents.insurance.name": req.body.name,
"documents.insurance.expires": req.body.expires,
"documents.insurance.url": req.body.url,
"documents.insurance.uploadDate": req.body.uploadDate
}
}, function(err, doc) {
if (err) throw err;
res.send('Success');
});
});
Even if I use a standard javascript date object I can print this on the browswer log
Mon Oct 01 2018 00:00:00 GMT-0400 (Eastern Daylight Time)
This prints on the sever just before mongoose
2018-10-01T04:00:00.000Z
But this is the end result in mongodb
2018-09-30T04:00:00.000Z
I think you and your server in different timezone. And mongodb uses GMT. If you are not declaring time in your iso date, it is setting it's time as 00:00.000Z. So for GMT this is one day earlier. Simply you should convert your date to GMT, you can use moment or you can fix problem by subtraction offset from date like this:
var offset = new Date().getTimezoneOffset() * 60000;
var date = new Date(new Date($('#insuranceExpiration').val())) - offset).toISOString();
or with moment.js
var date = moment($('#insuranceExpiration').val()).tz('GMT').format('YYYY-MM-DD');
I have a dt_birth property of type date. I would like to be able to search for a date in different ways. For example 1/13/1992, 01/13/1992, 1-13-1992, January 13, 1992. How could I go about this? Currently I can only search by the format I have implemented bellow:
dt_birth: {
type: 'date',
format: 'strict_date_optional_time||epoch_millis'
},
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
UPDATE: I am having a few issues comprehending this.
for the dt_birth format:
dt_birth: {
type: 'date',
format: 'strict_date_optional_time||epoch_millis'
}
How does the format specified above 'strict_date_optional_time||epoch_millis' effect the query format specified below:
{
"query": {
"range": {
"dt_birth": {
"gte": "01/13/1992",
"lte": "1-13-1992",
"format": "d/MM/yyyy||dd/MM/yyyy||d-MM-yyyy||dd-MM-yyyy"
}
}
}
}
Also, I'm a bit confused when you say add the date formats you need to support. How does the format correspond to the LTE and GTE? For example I would like to accept the date format January 15, 2000 - 1/15/2000 - 01/15/200 - 1-15-2000 - 01-15-2000. If I have 5 different formats I wish to support would that mean I would need 5 GTE/LTE? These last two questions are the most confusing. I appreciate any help :)
The definition of your dt_birth field contains the date format that ES expects to find in your document when you index it, so that it can retrieve the number of milliseconds (as a long) and index that.
At query time, you have the option to search by date by specifying any other date format using the format property of the range query:
{
"query": {
"range": {
"dt_birth": {
"gte": "01/13/1992",
"lte": "1-13-1992",
"format": "d/MM/yyyy||dd/MM/yyyy||d-MM-yyyy||dd-MM-yyyy"
}
}
}
}
or
{
"query": {
"range": {
"dt_birth": {
"gte": "1/13/1992",
"lte": "January 13, 1992",
"format": "d/MM/yyyy||MMMM dd, yyyy"
}
}
}
}
You can simply add all the date formats you need to support at query time in the format property and then simply fill the gte and lte properties with the appropriate dates. ES will happily parse them.
I have an app that uses the Calendar v3 API to create, query, and modify all-day events on Google Calendar. These events look something like this when I create them:
{
summary: 'My Event",
start: { date: '2014-07-26' },
end: { date: '2014-07-26' }
}
So if I want to query all of such events between July 20th and July 26th, I send a query like this:
GET www.googleapis.com/calendar/v3/{calendarID}/events?timeMin=2014-07-20T00%3A00%3A00.000Z&timeMax=2014-07-26T00%3A00%3A00.000Z
In a more readable format, the parameters are:
timeMin:2014-07-20T00:00:00.000Z
timeMax:2014-07-26T00:00:00.000Z
However, this excludes all of the events with the date 2014-07-26, it gets only the events for the 20th to the 25th. In my parameters you can see that I have used setUTCHours(0) in order to have no time zone information.
If I remove the calls to setUTCHours(0) for the timeMin and timeMax parameters then I have the opposite problem, I get 7/21 through 7/26 and miss the events on 7/20. How can I reliably get all of the all-day events for the week in any time zone?
Just came across this myself. For filtering, the end time is exclusive while the start time is inclusive. See the events spec here. Presumably when you just specify a date and not a time, it treats it something like 00:00:00 UTC -- so not inclusive of that day. But that's just speculation on my part. Anyway, if you +1 to your end date it should work the way you expect it to.
I would ask for +1 day on both sides of the week and post-filter the events that are not interesting.
The problem was with how I was creating events. To create an all-day event on date 1, you should set the start to x and the end to x + 1 day.
var dateStringStart = dateToString(dateObj);
var dateObjEnd = new Date(dateObj.getTime() + (24 * 60 * 60 * 1000));
var dateStringEnd = dateToString(dateObjEnd);
gapi.client.request({
path: '/calendar/v3/calendars/' + id + '/events',
method: 'POST',
body: {
summary: name,
start: {
date: dateStringStart
},
end: {
date: dateStringEnd
}
},
callback: function(eventObj) {
// ...
}
});