I've been banging my head against the keyboard for about a day now trying to figure out this time variance with momentjs.
I have an API endpoint that sets the time the request came in by calling
var now = moment().valueOf();
Then, it finds the beginning of the year by simply calling
moment(now).startOf('year');
After about 48 hours of seeding our DB with test data on a run, I noticed that the timestamp set in the database is December 31, 2015 (1451624400000).
When I run the program locally, the timestamp is January 1, 2016 (1451635200000).
When I log into our servers, create a test script to find the variance, and log the output, the timestamp is January 1, 2016.
Nothing is touching the time except for this one method in the api.
Is there some reason why momentjs would think the start of the year is December 31, 2015? If so, how do I change it? Haven't been able to find any help on this so far, and the moment.js docs explicitly say the start of the year is January 1 of the year.
I know this question has been around for quite sometime.
I faced similar issue and the solution to this is formatting the result.
var startOfThisYear = moment().startOf('year').format();
Thanks for the help, all.
It was a timezone issue, after all. I was overlooking a few things and had myself convinced I was testing consistently.
I had to configure the timezone on our Ubuntu machines with
sudo dpkg-reconfigure tzdata
We will be setting up NTP servers in addition for future prevention of such a variance.
Related
Working on flutter/dart project. Calling cloud function from client side and passing 2 dates which are converted toISO8601String.
Printing dates to console while executing cloud-function to double check. They are always valid. After creating document in firestore, the dates are shifted by 1 hour.
I guess because of my current timezone offset which is UTC+1. In summer I had same issue where firestore was shifting my dates by 2 hours because of summer time, resulting in offset UTC+2.
My cloud-functions are deployed at region: europe-west3, which according to firebase docs is Frankfurt. Same time zone as mine (Central European Standard Time). But when I create:
const now = new Date();
Result is one hour less than my local time. Why is that when we are in the same time zone with same offset?
Reading documents from firestore on client side results in inaccurate dates, which is pretty bad for me since I need it to be accurate.
I was searching everywhere but didn't find anything that really helped me. I was trying to construct the date object with many ways but the result was always the same, can somebody please explain me why and help me out? Thanks.
The Java Object Date does not actually contain timezone information, it's just a number of milliseconds since the "epoch" (01.01.1970 00:00:00 UTC) and thus an absolute point in time. It's converted into a valid time every time it's output to a user.
So it seems that the reason for the time shift is that your PC or the browser you are viewing your firestore documents from is set to the wrong timezone.
For further information, take a look at this question or the java documentation.
I am currently trying to create my own Google Agent using DialogFlow and while everything is going fine, I am finding myself unable to solve the smallest of problems.
Google has a tendency to add an additional year to the datetime object whenever I state a date. An example:
If I say "How much did we produce 29/6?" (6/29 doesn't work either) it will grab the date and format it correctly to the 6th of June, however it will make it year 2021 instead of 2020... Is there any way to make it default to our current year, unless I specifically say a different year?
Can you try saying "How much did we produce on June 29th?" I think it may have some issue processing the string "29/6" and somehow it gets translated to 6th of June.
You had mentioned "6th of June" is formatted correctly when giving "29/6", shouldn't it be "29th of June"?
I have a simple system, which on node creation form, allows user to select start and end dates along with hours and minutes:
The problem is that the date gets messed up somewhere in the middle, or I don't know how to convert it.
In the database, two values gets saved as follows:
start: "2019-08-01T14:00:00.000Z"
end: "2019-08-01T16:00:00.000Z"
Seems correct, as in the datepicker I chose 2pm and 4pm. Then, using momentjs and react-big-calendar, I try to put that event into calendar. It seems that it puts +3 hours every time. I assume, it is because it saves it in UTC format, and I live in Eastern Europe, which is +3 hours from UTC.
What is strange, is that I already get back time converted to my own when I make a request to the database:
Thu Aug 01 2019 17:00:00 GMT+0300 (Eastern European Summer Time)
Could someone help me out? I would expect to have the same hours returned and displayed, as I save them, meaning if I select 2pm, it should be 2pm. I think the solution here would be to ignore timezones, and always display everything in UTC? But how to do that? I have access to momentjs if that helps. I tried something like this:
moment.utc(event.start);
But it still returns the same value, which is:
Thu Aug 01 2019 17:00:00 GMT+0300 (Eastern European Summer Time)
When you setup React-Big-Calendar, you define a localizer. By default, the calendar will display in the local timezone of the browser the user is using. Any and all dates given to the calendar will be converted to that local timezone. If your dates, coming from the db, use an offset of +5, but you're sitting in +3, it will automatically convert those times to display +3 (part of the beauty of UTC).
This is where it can get tricky. Say I want to get all values from my db between Sep 19th and Sep 21st. I have to remember those offsets when requesting data from the system. I could use moment and say moment('2019-09-19').startOf('day'), and it would give me 2019-09-19T00:00:00Z, but this isn't exactly correct for me, as I'm at an offset of -5, which means I actually needed 2019-09-18T19:00:00Z to get the start of my day. The same holds true for my end datetime, where I would say moment('2019-09-21').endOf('day') and it would give me 2019-09-21T23:59:59Z, when I would need 2019-09-21T18:59:59Z.
Now, I'm not positive of this (you'll have to do some testing), but if you use moment-timezone instead of moment it may handle all of this for you. You'll have to play around to know for sure.
FINAL EDIT: I worked out timezone handling with moment-timezone as my localizer. I put the entire thing in a GitHub project, as well as creating a CodeSandbox where people can play with it.
TRULY FINAL EDIT: The (0.36.0) latest version of RBC has full timezone support now, when using either the momentLocalizer or the new luxonLocalizer. Doc site isn't up to date yet, but if you run the 'examples' locally you'll find all the info.
EDIT: I really don't know what just happened right now but I was still looking over the dashboard for some other infos and the statistics just reseted! I'm sorry for posting! For anyone wondering, I think the quotas reset at 10 AM (EET)
I'm working on a work certificate in informatics and I decided to give Firebase a try with this project. I love it :)
Two days ago, when I started, everything was good. Yesterday at 8 PM I think I reached the quota for bandwidth (1GB) so I said, "ok no problem, I'll work on it tomorrow". Now today when I opened Firebase Console I still get this error in Storage: "You have exceeded your quota for this project. Please upgrade your plan."
I will leave here a few screenshots with my statistics. Can anyone help me figure out why my limits did not reset? PS. The error first showed up at maybe 8 PM yesterday and now it's 10 AM. It's another day but 24 hours didn't pass. Is this the real reason? I read on another StackOverflow question that it resets daily so I thought that at 12 AM it resets.
Thanks in advance!
You can see in this picture that on 15 December (yesterday) I have 1GB hit but on 16 December (today) is 0.
However, if I set the calendar to show me "Today" instead of "Current billing period" it shows me that the bandwidth was used today
So my question is, the quota is working on a 24 hours base or daily base?
read the fine print ...it reads 1 GB per day for Storage.
it does not tell when it resets - and might eventually depend on the zone & region.
try to use smaller files for testing purposes.
GWT doesn't serialize Java Date properly. When I tried sending Date created in Javascript through the wire, I found out that dates between April 1st (funny) and 25th October for years before year 1983 get subtracted by one day.
That means that, say, both 1982-04-01 and 1982-03-31 become 1982-03-31 on the Java side.
Given the dates in question, I would guess that this is some kind of DST problem. I've tried googling, and found only one other reference that describes similar problem.
I also tried submitting bug to the GWT team, but curiously wasn't able to find bugtracker for GWT.
So, my questions are:
Anyone else run into this? I'm on GWT 1.7, and would like to confirm if this happens on 2.0 as well.
My workaround was to send dates as Strings, and parse them on server. Anyone knows better workaround?
Assuming that you are using a java.util.Date
Question 1: It seems that it is fixed in 2.0. I've created both Dates above (1982-04-01 and 1982-03-31) and they come through correctly to the server (both represent on the server as 1982-04-01 and 1982-03-31 respectively). My setup is:
GWT 2.0
Java 1.6
OSX 10.6.2
Question 2: You could always pass the 'milliseconds since January 1, 1970, 00:00:00 GMT' over the async service-which you can get using getTime() on the date object. On the server side you can then instantiate a new Date passing this value in on the constructor:
Date date = new Date(millis);
This saves fiddling around with formatters and parsers.
Dates and times are a complicated subject. The conversion can depend on the locale that the browser is running in and wether both you JVM on the server and the locales of the clients are up-to-date.
In some cases there can be differences because in some regions they switched timezones in the past.
GWT sends dates using just millis since epoch time. Since it is using Date objects, you are limited in that the Dates on the server side will be automatically modified to the servers timezone. Are you sure that you take into account the possible difference in timezones between client and server ?
David
I'm pretty certain the FTR library has some date emulation in it.
http://code.google.com/p/ftr-gwt-library
If you don't have to do client-side conversions (adapt to user's timezone) or calculations send it in a String from the server.
Never came across your specific problem though.
The possible problems soure is difference in Client/Server time zones.
We have also run into a similar problem. It was long enough ago that I do not remember the exact details but the gist of it was there were some minor differences between java.util.Date and the way dates were handled in Javascript. Our workaround was effectively the same as yours, where the actual value sent over the wire was generally a String.