|
Sander Rossel wrote: Will we ever learn?
Because Each One is a Tragedgy[^]
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
|
When they say a picture is worth 1000 words...
Frankly it's disturbing.
|
|
|
|
|
Today, here in Belgium it is an official holiday but man it is not a festive one. Here we see the untold thousands of graves of soldiers who fell in WW I, never mind the 55000 or so who went missing carved into the Menen gate in Ypres and so many others at different locations.
Don't let it happen again, the price is far too high.
|
|
|
|
|
So I have this super simple use case.
I have a starting time and an ending time and I want to calculate the total time between them (just hours and minutes).
I use three time inputs in HTML and set up an event handler on the change event of the start en end times.
My initial thought was something like total = end.value - start.value, but unfortunately, the value is a string.
Search around and I can do Date.parse(start.value) to get an actual Date object... But wait, no, it returns an integer representing the milliseconds since 1970...
Now, new Date(Date.parse(start.value)) gives me a proper Date object.
But, the control gives me the date of 1970 since the date doesn't matter because it's a time only input.
However, the other control probably still has the date set from the (C#) back-end.
So, get Date.now, which also returns milliseconds, so new Date(Date.now), and set both dates to today so I can calculate the difference.
And now it all goes to hell.
The input assumed UTC, I think, while the Date object somehow corrects for my time zone (UTC + 1).
Or maybe the Date is neutral, but the eventual toISOString isn't (same result with toString though).
Whatever it is, it only does this for the value I just edited, so my result is off by an hour.
Tried all kinds of stuff, always off by an hour.
Even when I manually correct for the difference, there's ultimately a difference.
Ended up reading the string from the input, manually substringing the hours and minutes, build two new dates using nothing but setUTC methods and then subtracting those.
That works and I can easily correct for times like 23:00 (start) and 01:00 (end) by adding a day to end when end > start (the difference well never be larger than a couple of hours, certainly not 24 hours).
HOW ![Elephant | [mastadon]](https://codeproject.freetls.fastly.net/script/Forums/Images/elephant.gif) ING HARD CAN IT BE!? 
This kind of sh*t is exactly why I hate (front-end) web development with the burning passion of a thousand suns.
And don't even get me started on CSS 
The reason I'm so pissed is because it took me until 01:30 to fix this, went to bed all worked up and didn't sleep until 04:30
Gave me a sore throat to boot 
Really, JavaScript
|
|
|
|
|
Should be fairly simple with a small library:
Day.js[^]
Luxon[^]
You could also use Moment.js[^], but it's no longer recommended[^].
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Yeah, I was thinking about Moment.js, but I know it's no longer supported.
Too bad too, I really needed that Klingon format 
I didn't know Day.js and Luxon, but they look promising.
I didn't want to use a library for something this simple.
I dislike using libraries for a single line in my entire application (unless it's really something complex).
Then when I found out it wasn't that simple it got personal and I wanted to fix it myself.
At least it works now and I'm the wiser for it 
|
|
|
|
|
Not that I can explain it for your case, but it seems the two dates (times) are in different timezone...
I work a lot with dates and times in JS and functions that handle dates and times are part of my base library...
What I've seen is that JS will try to be super smart and change the timezone according to your date, even it is totally BS...
For instance, working with local - Israeli - time - times with 01/01/1970 as date part will add 2:30, while times with today as date part will add 3 hours... Totally nuts!
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: times with 01/01/1970 as date part will add 2:30, while times with today as date part will add 3 hours... Totally nuts!
That's probably the problem I had as well!
The date I just edited was always in 1970 (and had the off hour) while the other date was always today (or tomorrow).
Maybe time zones switched somewhere between the 70's and now? 
Kornfeld Eliyahu Peter wrote: Totally nuts!
JavaScript: The Definitive Guide! 
|
|
|
|
|
There were (and are) changes... And not all countries have nice 1 hour jumps, it can be half or even a quarter hour...
It seems that JS try to follow the course of history but gets lost...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
Sander Rossel wrote: Maybe time zones switched somewhere between the 70's and now?
Lots of times! 
And future time-zone changes are why you can't always rely on storing UTC:
Storing UTC is not a silver bullet | Jon Skeet's coding blog[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Actually storing time as UTC is wrong a lot of times...
I'm working a lot of with courses, and if a meeting in the course is at 8:00 than it is at 8:00 even if its DTS or not... It should not move to 9:00 or 7:00 when moving the clock...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
I guess you should store UTC and time zone separately and then adjust for the stored time zone every time you show the data 
Although if you have a meeting at 9:00 (first thing in the morning) and you plan the meeting in UTC+2 you still want to see 9:00 when the time moves to UTC+1 if everyone is in the same time zone as you.
I recently had this issue when I was invited for a meeting in Canada in time zone x while I was in time zone UTC+2, but UTC+1 at the time of the meeting.
They should really just abandon time zones altogether.
People in England would live from 08:00 to 23:00, Europe from 09:00 to 00:00 and USA from 14:00 to 05:00 (or whatever, haven't done the math on that).
At least when you plan a meeting at 09:00 everyone will have the same time and for some it will be during day while for others it will be during the night.
On the other hand, when someone says they have to be at work at 18:00 you have no idea if that's late or early in their specific region.
Plan B, abandon the sun so everything's dark all the time and we can all live at the same time because there's no night or day anyway
|
|
|
|
|
You are doing it all wrong. Do it like today's generation.
"Hey Siri, How much time between time1 and time2? "
eezy schmeezy.
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
Bummer, dude. Take a break ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
1) Press F12 (while viewing this page)
2) copy the code below
3) paste it into the console and run it
let startTime = Date.now();
setTimeout(()=>{
let endTime= Date.now();
let timeSpent=(endTime-startTime)/1000+" seconds.";
alert("It took " + timeSpent + " to complete");
},Math.floor((Math.random() * 8000)));
It'll set a timeout that will last between 0 and 8 seconds.
When the timeout fires, it will calc times between startTime and endTime (in seconds) and display the value in an alert.
Does calculating the time between those two times not work?
It's an interesting coincidence because I just used the time measuring code in some JS I wrote yesterday.
There is also the new(er)
window.performance.now()
Update
Just noticed that it sounds like you are saying you "have a start and end time"...maybe as a string. that's a lot more difficult. 
|
|
|
|
|
I think the "problem" with my code is that the value comes from an input field.
Your code seems to work, but I don't think I'll notice a time zone difference in seconds 
|
|
|
|
|
Sander Rossel wrote: but I don't think I'll notice a time zone difference in seconds
Yeah, I was thinking that too, but I just wanted to provide some code that would show a difference in two times. Good luck with it.
|
|
|
|
|
I feel your pain. I avoid front end web work like the plague.
Real programmers use butterflies
|
|
|
|
|
That means a lot coming from someone who writes parsers, lexers and MIDI libraries! 
|
|
|
|
|
And not a one with any javascript code in it!
Real programmers use butterflies
|
|
|
|
|
Sander Rossel wrote: The reason I'm so pissed is because it took me until 01:30 to fix this, went to bed all worked up and didn't sleep until 04:30
So is that 3 hours til you got to sleep? Or 4? Or 2? What does Javascript say?
|
|
|
|
|
JavaScript says "sweet dreams" before smothering me with a pillow.
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
