When getting some records, I'm seeing that some dates are showing as GMT-0400 (EDT) and others are GMT-0500 (EST).
Dates are being added in mongoose simply by using Date.now in the schema.
Any ideas what could cause the offsets to be different?
Edit: Here's an example:
Stored as: ISODate("2015-10-30T15:36:47.287Z") Returned as: Fri Oct 30 2015 11:36:47 GMT-0400 (EDT) using find() with Mongoose
Stored as: ISODate("2015-11-07T14:44:47.956Z") Returned as: Sat Nov 07 2015 09:44:47 GMT-0500 (EST) using find() with Mongoose
It's just the default string representation of the underlying UTC timestamp, showing the timestamp in the local time zone that was in effect at the time.
In 2015, daylight saving time ended at 2:00 AM on Nov 1, so that's why the first one is shown in EDT and the second one is shown in EST.
Any queries you do are always performed using UTC time.
Related
I have a DB with entries in Universal Time such as this:
{"problemDate": "Mon May 11 2020 13:09:14 GMT+0000 (Coordinated Universal Time)"},
{"problemDate": "Mon May 11 2020 13:09:14 GMT+0000 (Coordinated Universal Time)"},
{"problemDate": "Mon Dec 07 2020 14:08:26 GMT+0000 (Coordinated Universal Time)"},
{"problemDate": "Tue May 12 2020 00:18:21 GMT+0000 (Coordinated Universal Time)"}
Although, I am trying to query for a range of dates, my db has around 2k entries with dates ranging from May to December. If I query for dates greater than December 7th, my return still shows dates such as Mon May 11. I believe this is because my dates are just strings. I was wondering if there is a work around to this. Any help would be appreciated.
This was my query:db.problem.find({"problemDate":{ $gte:("Mon Dec 07 2020 14:08:24 GMT+0000 (Coordinated Universal Time)") }});
You could try an update on the collection to convert the dates from string to IsoDate.
The following script it's designed to run in a mongo shell, and it's assumed that you have selected the database (use databasename) and your collection name is 'datestest':
db.getCollection('datestest').find({}).forEach( function(item){
if (typeof(item.problemDate) == "string"){
print(item.problemDate);
item.problemDate = new Date(item.problemDate);
db.getCollection('datestest').save(item);
}
}
);
You can first save the "bad dates" to a different collection to check the update it's all right, just replace the save item with a diffrerent collection name:
db.getCollection('datestest_check').save(item);
I am working with an API that generates time periods based on a configured set of parameters.
So for example, I can specify I want 12 one month periods starting Jan 1st at midnight, and therefore the API will generate 12 monthly periods
01 Jan 2016 00:00:00 – 31 Jan 2016 23:59:59
01 Feb 2016 00:00:00 – 28 Feb 2016 23:59:59
Through to
01 Dec 2016 00:00:00 – 31 Dec 2016 23:59:59
Now the API expects a start date param supplied for the sequence of periods to be an ISO formatted string in UTC. So I’m currently in the UK, therefore if I choose to start the monthly periods from Jan 1st 2016 this would be 2016-01-01T00:00:00Z and is what I supply to the API call I am making to say when the first instance of my monthly periods should begin.
So now if I view the start and end dates of the generated monthly periods via the API, I will see them come back as
2016-01-01T00:00:00Z - 2016-01-31T23:59:59Z
2016-02-01T00:00:00Z - 2016-02-28T23:59:59Z
Etc to
2016-12-01T00:00:00Z - 2016-12-31T23:59:59Z
Something struck me about these generated periods and that is I want them to begin at midnight for where I currently am, but a period that is affected by GMT Daylight Time, so say my April period will look like so in the generated period from the API
2016-04-01T00:00:00Z - 2016-04-30T23:59:59Z
Parsing the start date for the above into a date object for viewing in the client (on my machine) will show up as
Fri Apr 01 2016 01:00:00 GMT+0100 (GMT Daylight Time)
So it’s saying that period starts at 1am and not midnight.
Now say if I wanted 12 months to be generated from 1st Jun when Daylight Savings is in effect.
My client side code currently will supply a start date to the API of 2016-05-31T23:00:00Z. This causes the API to generate start dates for each monthly period as being
2016-05-31T23:00:00Z - 2016-06-31T22:59:59Z (June Period)
2016-06-31T23:00:00Z - 2016-07-31T22:59:59Z (July)
Etc to
2017-04-30T23:00:00Z - 2017-05-31T22:59:59Z (May)
But now for a period that is not in GMT Daylight Time, so Jan for example it will show up as
2016-12-31T23:00:00Z - 2017-01-31T22:59:59Z
Meaning my client will see that start date as
Sat Dec 31 2016 23:00:00 GMT+0000 (GMT Standard Time)
So not Jan 1st at 00:00
Does this suggest that the API should know about the users timezone so the period generation logic in the API can factor this is when calculating the start and end dates?
Maybe I'm over thinking things here?!
The only real question I see here is:
Does this suggest that the API should know about the users timezone so the period generation logic in the API can factor this is when calculating the start and end dates?
In general, the answer is YES. Any time you are mapping calendar dates back to specific instants in time, then by definition you must involve time zones. That time zone can be that of the user's, or of some specific business location, or fixed to UTC, but they indeed part of the logic.
Consider that not every calendar date has a valid local "midnight" in every time zone. An example is 2015-10-18 in Sao Paulo Brazil, where the first moment of that day was 1:00 AM due to their spring-forward daylight saving time transition. There are many other examples of this around the world.
The only way to avoid the problem entirely is to not deal in specific times. If you are only working with whole dates, then your code can certainly compute the exact dates of each month without knowing anything about time zones. 2016-01-01 through 2016-01-31 has no awareness of time or time zone. It's only when you try to ask what the current date is, or if now is within that range, or if some other specific instant in time is within that range that you have to start thinking about time zones.
I'm having problem to filter tweets by specifics dates, using setUntil come no tweets, using setSince come recently tweets.. The code is following and after that the output result..
public void readTweetFromKeyword(String keywordString) throws TwitterException
{
twitter4j.Query query =new twitter4j.Query("#clt20");
QueryResult result;
query.setSince("2014-12-12");
int cont = 0;
result = twitter.search(query);
for (Status status : result.getTweets() )
{
System.out.print("original "+status.getId());
System.out.println("\t\tdata "+status.getCreatedAt());
if(!status.getText().substring(0, 2).equals("RT")){
System.out.println(status.getText());
cont++;
}
}
System.out.println(result.getTweets().size());
System.out.println("cont = "+cont);
return;
}
CONSOLE:
original 619433499116896256 data Fri Jul 10 06:10:29 GMT-03:00 2015
If the #BCCI is looking for an alternative to #Clt20, then how about a
league of teams consisting of only Indian players ?
original 619408117495939072 data Fri Jul 10 04:29:37 GMT-03:00 2015
#TesT, #ODI, #T20I, #IPL, #CLT20 Live record, score, history shedule ke lia, Follow #PTV_SpOrtsOne snt to 40404.
original 619330143258050560 data Thu Jul 09 23:19:47 GMT-03:00 2015
Need 66 From 6 Balls. Kinda Impossible #clt20
original 619301555532120065 data Thu Jul 09 21:26:11 GMT-03:00 2015
Kamran Akmals feet are stuck #soshit #CLT20
original 619095093962608640 data Thu Jul 09 07:45:47 GMT-03:00 2015
original 619095079983017984 data Thu Jul 09 07:45:43 GMT-03:00 2015
original 619095051524665344 data Thu Jul 09 07:45:37 GMT-03:00 2015
original 619095028304973825 data Thu Jul 09 07:45:31 GMT-03:00 2015
original 619094989943902209 data Thu Jul 09 07:45:22 GMT-03:00 2015
original 619094910516400129 data Thu Jul 09 07:45:03 GMT-03:00 2015
original 619094893441363969 data Thu Jul 09 07:44:59 GMT-03:00 2015
original 619035151578722304 data Thu Jul 09 03:47:35 GMT-03:00 2015
#abhisek_taneja Games r played in Himachal Pradesh every year if u go
through the schedule of #IPL & #CLT20 properly
original 618914815730290688 data Wed Jul 08 19:49:25 GMT-03:00 2015
original 618908444939186177 data Wed Jul 08 19:24:06 GMT-03:00 2015
original 618862474687705088 data Wed Jul 08 16:21:26 GMT-03:00 2015
We as #T20 follower , #clt20 should be oganized #CLT20
15 cont = 6
Thanks a lot!!
If you set an until date kepp in mind this from the documentation
Returns tweets generated before the given date. Date should be
formatted as YYYY-MM-DD. Keep in mind that the search index may not go
back as far as the date you specify here.
And this too
Before getting involved, it’s important to know that the Search API is
focused on relevance and not completeness. This means that some Tweets
and users may be missing from search results. If you want to match for
completeness you should consider using a Streaming API instead.
So, if you set an until date too old you could get zero tweets, in the other hand if you set a since date too old you could get only tweets from the few past days as you get in the console.
I have a date time in format: Mon Jun 11 12:16:14 EDT 2013
I want it inserted in postgres as Date attribute, but postgres always inserts the current date time. I think it is the issue with the format. The normal date format in postgres is something like: 2012-06-13 04:24:45
How could I change Mon Jun 11 12:16:14 EDT 2013 format compatible to postgres?
Thank you!!!
You want the to_date or to_timestamp function.
You give it your string date, and a patten for how to parse the date. For your example it would be:
select to_timestamp('Mon Jun 11 12:16:14 EDT 2013', 'Dy Mon DD HH24:MI:SS ??? YYYY');
to_timestamp
------------------------
2013-06-11 12:16:14+01
I don't think you can't work with the timezone with these functions unfortunately (hence the ???)
You should also just be able to cast the string like:
'Mon Jun 11 12:16:14 EDT 2013'::timestamptz;
I'm using MongoDB 2.2 with java-driver 2.10.1
I'm inserting a date field into a document from a java.util.Date instance. My instance has the following value:
Wed Oct 10 00:00:00 CEST 2012
but once in mongo, I have this value:
ISODate("2012-10-09T22:00:00Z")
My insertion code:
BasicDBObject doc = new BasicDBObject("key", event.getKey())
.append("title", event.getTitle())
.append("description", event.getDescription())
.append("date", event.getDate());
db.getCollection("events").insert(doc);
You can have a look to the date instance referenced from my event object on this debug screenshot:
Is there something to do with the timezone ? Or a bug from the driver ?
Dates in MongoDB are always stored as UTC datetimes, so what you're seeing is correct.
The CEST time zone is two hours ahead of UTC (GMT) so your time's correct UTC representation is two hours earlier than your CEST time, which is exactly what you're seeing.