I always copy data from yesterday in a spreadsheet every morning.
So this is yesterdays data:
When I click on the right “>” next to the date and advance to today
Today != Yesterday
This is only on my desktop with web browser.
My android app is okay
os: debian linux
browsers tested:
brave Version 1.46.99 Chromium: 107.0.5304.91 (Official Build) beta (64-bit)
&
firefox 108.0a1 (2022-10-22) (64-bit)
Same here. Wonder if this is a side effect of my other post.
Actually it’s all probably related to DST as I seem to remember having issues the last couple years. Not like this tho.
Let’s hope next year there will be no more DST.
That would solve a lot of issues for a lot of /[removed/] programmers
Lol we can only hope & pray. I understand how it can create issues, but it’s not like DST wasn’t expected…
If/when after years of DST sense doesn’t has this figured out…
What can I say …
1918 (first used in USA) & 1966 (uniform use in USA) wasn’t all that long ago.
Still can’t figure out how having to turn the lights on at 3pm instead of 4pm “saves energy”.
Guess we really are stuck in the past, trying to make Sense of how yesterday is today’s now. 
@dannyterhaar
Check out my related thread: What the heck is going on?
When I go to web page with a browser (tried both chrome & firefox)
Today, Saturday Nov 19 2022, when I go to yesterdays page:
That is correct.
When I click on the Arrow on the right, it should advance one day to today, right?
So “Yesterday” is today
My bill ends around the 14th of the month and I set it accordingly in Sense.
When I want to see my new bill stats so far (so starting 15th) i should see 4 days of usage already
But …
The title is right “Nov to Dec” bill
But the data is from “Oct to Nov” bill.
So the whole MONTH is off by one!!!
Since there are now 2 threads already about this (probable) DST issue.
Why hasn’t anybody from Sense made an official reply/announcement and/or why hasn’t this been fixed already ?
It has only been 2 weeks since we had the DST change…
I am not sure this is related to DST. For example, right now where I am it is 6PM PST. I go to the detailed paged for “day” and it is labelled as “Yesterday”, but clearly shows a partial day usage (for today, as expected). I can also confirm that display has the correct data for today by comparing with my sun power monitor (which is independent). If this were a DST issue, it would likely only be wrong for about 1 hr around midnight, but this is wrong all day long, everyday.
So it seems that the code for determining the label above the graph is just wrong and calls “Today” "Yesterday. Going back one day does provide the correct label for what is actually “Yesterday”, but just calls it by its date. I can confirm that (a) the iOS application does not do this (wrong), and (b) that the API used to obtain the actual data from sense does not supply labels like these. Therefore, both mobile app and web app have their own code to convert data from the API (trends data) that only contains dates to fancy labels, and the web api is doing it wrong.
The issue with the bill page is something I am seeing too. My cycle turns on the 10th, so I would expect to see partial month data (about 9 days worth) for the current bill. Yet what I see is labelled Nov to Dec 2022, but the graph below it has data for Oct 10 through Nov 9. The problem here is two fold: (a) there is no way to “forward” to the next partial month, or in other words cannot use the web UI to see that partial month, and (b) the labelling is wrong because for what I see it should have been labelled “Oct to Nov 2022”. As an aside I think they should really say Oct 10 - Nov 09, 2022 (for my case).
Here, again, the web gets it wrong, the mobile app gets it right, showing a correct label and partial month.
In the end I think it is not (directly) related to DST changing. The data from the API seems sound and does not use such relative data labels as “yesterday” etc. It may appear related because perhaps changes were made to the code around that same time.
Another thing that I find strange is that I don’t get this “overview” that you are showing (Product, Usage, To/From Grid" etc. I suspect you are using some different version of the web app (I am using regular home.sense.com). I think I saw some about a beta version, but don’t know how to get it.
Thank you for wording it way better than I can 
I think it is DST related since it started happening after ending DST.
Like you say, the interpreter of the web page somehow because of either a 23 or 25 hour cycle is off by one day and that leads even to the off-by-one-month with solar usage.
Btw: This is the regular website
See also this thread:
Ha!
Thanks for reminding me I have a possibility to look at the beta web page as well!
To my surprise the BETA page shows everything NORMAL!!
Today == TODAY!!!
And the new billing period:
As it should be!
So Sense has a beta channel.
But they choose to put the new changes directly in production.
And now the beta website is “normal”
and the stable/normal website is broken.
I was able to glance the beta url from your post, so I tried it. Still don’t get the “extra stuff” under solar.
Any idea why not?
Regarding beta vs regular, currently I find:
14.0.1-2a7c646
13.0.1-a1b3320
So yes, it very much looks like “beta” is not really beta, at least not today. It runs a major version behind!
Regarding the labelling mishap… I found the Javascript code that does the formatting. It is, indeed, different between the beta version and the regular version (code has been “minified” so looks a little odd):
// In homebeta.sense.com code
function c(e, t) {
var n = i()(e).startOf("day"),
r = i()().startOf("day"),
a = i()().startOf("day").subtract(1, "days");
return n.isSame(r) ? "Today" : n.isSame(a) ? "Yesterday" : n.format(t)
}
// In home.sense.com code
function c(e, t) {
var n = (0, a.AH)(e, { startOf: "day" }),
i = (0, a.AH)(new Date, { startOf: "day" }),
o = (0, a.AH)(new Date, { startOf: "day", minus: { days: 1 } });
return (0, a.Xy)(n, i) ? r.ZP.t("today") : (0, a.Xy)(n, o) ? r.ZP.t("yesterday") : (0, a.S$)(e, t)
}
The equivalence between the two sections is variable “n” is the same in both, “r” is “i” in the second one, “a” is “o” in the second one. Computations for each are the same. “n” is the start of the day of some time passed in as “e”. “r” is the start of the day in the web browser’s current time, and “a” is the start of yesterday compared to the web browser’s current time.
Another big difference in the code, immaterial to this discussion, is that the “regular” version contains lots of code to make the site localizable, whereas the beta version does not. In general I am assuming that (0, a.AH) is equivalent to the i() method, and (0, a.Xy) is equivalent to the isSame method. r.ZP.t looks up a translated string in a table.
With that said, it looks like the return expression in both is equivalent as far as “today” and “yesterday” is concerned. Yet we get different outcomes. The explanation might be that the value passed in “e” is different between the two versions. Another possible explanation is that the lookup table used by the regular version (for localization) has the wrong text associated with “today”, but from what I can tell this is not the case.
I also noticed that a very similar calculation is done elsewhere in the code, but using a completely different piece of code! This is true in both versions. In general this code does not strike me as high quality code…
Keine blasse ahnung (I honestly have no idea)
What browser are you using ?
I am on Linux desktop and tried with both Google Chrome derived Brave browser & firefox
I see them in both my browsers.
Could you try your mobile device as well?
In brave on my android phone, set your browser to " desktop site" (otherwise the web page redirects you to install the sense app) and go to: Sense
Is that what you see at settings → about ?
I have 14.0.1-2a7c646 as well!
Yep, and that is why is still working.
Defeats the whole purpose of having beta releases doesn’t it ?
Given the fact that this company has had several rounds of financing and there are certainly enough smart people working there, why is the QC so lousy ?
And if you have an active community, why isn’t the feedback (breakfast of champions) used in a way to solve issues fast/efficient ?
I would be ashamed to have to represent a company that makes these kind of mistakes.
Of course, I grew up in a different culture where you could not sue someone as easy.
But my company had 85 employees and ten-thousands of customers and we had a few persons on it to correct things. And at least acknowledge that the feedback was noted and giving a time frame to try and fix it. It turned way more difficult we would update our customers and produce a new time frame for the fixes/improvements.
Proud to say we were nearly 10 years chosen as one of the 2 best in our field.
I really miss that commitment at this product/company.
OK, you gave me the clue. It shows in Chrome on MacOS, but not in Safari, which is what I predominantly use.
Having founded a tech company in Silicon Valley and lived in that environment for over 30 years, I can tell you that what happens at a company is not frequently driven by good technical sense. In particular investors need to be kept happy, which causes management to chose to do things to appease them. Not saying this is happening here, but iff the long term goal for a business is not necessarily keeping individual customers happy you might see this kind of behavior. Perhaps having an eye on a large institutional buy-out (which allows investors to cash out), or being busy, behind the scenes, which an alternate business model is keeping management interests away from what you would think makes common sense.
I have also frequently seen, although more typical in the mobile app space, the companies vastly underestimate what it takes to have high quality development done. They don’t budget enough for it and end up outsourcing it to supposedly “cheap” places. Management often does not see how this hurts, in the end, and often times if the product is successful and the revenue stream does not depend on the software directly, it never becomes a pressing issue. The good news for me was that I was often hired to “fix” the problem once it became untenable. At that point it inevitably costed a lot more money to fix than it would have costed to do it right in the first place.
Update: Sense is still investigating the time issue.
Aka, still Sense employees are still learning how to tell time.
Once they accomplish that, they will have the even more daunting task of trying to figure out how to change the time.
I fully imagine they will apply a fix shortly before March 13 2023 and immediately forget their knowledge thus resulting in our monitors showing “tomorrow”.
I believe they fixed it!
The web page on the normal url home.sense.com says “today & yesterday” again at the right graphs!
20 days since I opened this thread and the ticket.
I still think it is connected to ending DST on Nov 6th.
Version of the “normal” web page has been update to 14.0.2-68c24e5 (was 14.0.1-2a7c646)
So just an update, sneaked in without any announcement.
I kind of would have expected them to chime in here and say something along the lines of
“we fixed it. It was so and so and we will keep an eye out next change of DST (if we ever get another) if we fixed it right”
But I was only dreaming that part of course …
under 
FINALLY!
11/22 Pranav, “Either myself or another agent will be in touch.”
11/23 George, “Once we have an update for either issue our team will follow up with you directly.”
11/28 George, “Once we have an update for either of the two ongoing issues we will let you know.”
11/28 George, " We will be in touch with you once we have an update for either issue."
Hi all,
I just wanted to say that, yes this issue should be resolved. I was going through the backlog of reported issues and saw this came up in more than one engineering ticket. Sorry for the lack of any announcement here, but I just wanted to let you know I saw this and wanted to put this one to bed. Let me know if you have any questions. Thanks again!
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
