Time… a programmer's worst enemy // The Code Report
HTML-код
- Опубликовано: 16 мар 2022
- Keeping track of time is complicated for programmers due to leap seconds, timezones, and the weirdly designed Gregorian calendar. A new bill is going through congress to make daylight savings time permanent - here's what that could mean for developers.
#compsci #programming #TheCodeReport
🔗 Resources
Daylight Savings Bill www.reuters.com/world/us/us-s...
Try the Temporal API tc39.es/proposal-temporal/docs/
Why JS Dates Suck maggiepint.com/2017/04/09/fix...
🔥 Get More Content - Upgrade to PRO
Upgrade to Fireship PRO at fireship.io/pro
Use code lORhwXd2 for 25% off your first payment.
🎨 My Editor Settings
- Atom One Dark
- vscode-icons
- Fira Code Font
🔖 Topics Covered
- How do timezones work?
- What is a 13 month calendar?
- What is the Gregorian calendar?
- Timezones explained for programmers
- How to use JavaScript Temporal API
- What are the most hated features in JavaScript? 
Наука
At first I totally thought this was going to be a video about how little "time" we have as devs to get features done ... In time ✅
Same for me, I was quite surprised because the title wasn't really appealing to me, but the video was interesting, as always :)
That's really is my biggest enemy, sometimes times passes way too fast
So Im not the only 😅
so did we, but It ended up being a click-bait
+1 😁
There are two types of programmers, those who prepare all their software to be future-proof, and those who think that no one will use their code in the future. Interestingly enough, it seems that the software made by the second type of programmers is the one that will always be used in the future.
Probably because they get it finished quicker, and so gets the first-mover advantage.
I mean, naturally. The future-proofed code is protected from the future, just as a bulletproof vest is protected from bullets and anything fireproof is protected from fire. This means the future is forced to pick the other, non-proofed code instead!
Non-future-proofing is a dominant allele. Any code that calls non-future-proof code, no matter how well-written, isn’t future-proof. Bad planning spreads through the world of code like a virus.
@@nyankers I hate that my monkey brain is telling me your right!
You can’t have a future-proof code. You can only have a some future-proof code. There are many things that can happen in the future and you can foresee only some of them. That’s why you see a bunch of code becoming deprecated
ALWAYS use UTC+0 when you work with datetime and saving it in databases.
Only convert it to localtime when displaying it in the UI to the user.
@Imbe Tahimoto i prefer UTC*1
or just uses unix epoch
UK format with slashes only sorry
All the functions besides the UTC ones might as well not exist. I made the mistake at first to use the other ones and dear lord it was so inconsistent it was nonsensical.
This isn't a silver bullet at all. Saving UTC doesn't work when you have to account for future dates. These future dates may be in timezones which will be completely abrogated later, or daylight saving may come around. In that case, you need to save the date as-is along with the timezone and timezone version
"are you sure making months zero indexed won't be annoying?"
"bro it's literally just a Javalibrary in the 90s, this will not have long term consequences"
>still using zero indexed months 30 years later
:|
So true it hurts..
That does hit the sore spot.
Nothing is more permanent than a temporarly solution.
Great timing. Today in Poland hundreds of trains stopped in their tracks because of a 'time formatting' error in the traffic control software.
I see what u did there. *timing*
Great timing!
This code report coming out around the time the US is changing their time. Coincidence?
One thing to nitpick is that the world has moved away from GMT. It's called UTC now. What's the difference? UTC takes into account the leap seconds, which weren't a thing when GMT was defined.
UTC isn’t actually a time zone, it’s what they call a ‘time standard’ so no country actually ‘uses’ UTC. It’s still a bit weird though.
@@max-c14 if no country uses UTC and GMT is wrong then what do countries use?
@@tudorpop3579 they have their own time zones. America has loads but you can search them up.
@@tudorpop3579 GMT is technically now considered a time zone, and every time zone derives their local time from the systems outlined in UTC. But UTC is a specification which sets the time, handles leap seconds, etc.
Quirky note: there's proposals to replace UTC with a system which defines time differently (and doesn't make use of leap seconds). If passed in 2023, GMT would derive local time from NEW_SYSTEM instead of UTC.
GMT is actually not well defined. If you look at the legal definition, it’s not clear whether they’re referring to UT1 or UTC. Since the two could differ by up to 0.9 seconds, you can see where a problem comes in.
This is the some of the best tech content on RUclips. Definitely my favourite channel.
For a junior, maybe. As a senior dev I see that the author often makes videos about topics he is not experienced in. They are nicely presented, but the content is not the best sometimes. That's the case for JavaScript
-related videos, especially frameworks.
@@rafadydkiemmacha7543 that doesn’t bother me much. What I like is the short and high-level format. It’s hard to be specific and concise at the same time, and I think the author handles that compromise nicely.
@@raynem526 yeah, but I don't think this channel deserves the title of "best tech content". Best presentation, maybe.
@@rafadydkiemmacha7543 I would say best entertainment tech channel, maybe? :)
@@ondrejhabina7163 makes sense, I love watching these videos too.
Thought that the video was about deadlines, which is my worst enemy
As a Java developer working on legacy code most of the time, every time I come across the old date API I shiver. It is horrendous, and I'm glad we have the new stuff to play with. So. Much. Better.
As a new grad java developer working with "new code" done by Java 6 developers, I agree. I've been pushing HARD to move every single date-related thing to java.time. No luck so far, but the very wonky shit we have to do to get dates right, the ocasional "The ORM know how to work with the new API, though" and my constant "We should use LocalDate" git comments on bug fixing are starting to bloom.
@@JettoDz Keep up the good fight! And remember the ground rules. Instant for things that happened, zoneddatetime with zoneid for appointments in the future (in case the timezones change), and localdates if the date is all you need.
The Kodak calendar of 13 months of 28 days is sooo great!
Every month would start on the same day of the week (so Monday or Sunday, for example), and there would be a final extra "year day" to get 365.
A similar calendar is the Ethiopian, which has 12 months of 30 days and a thirteenth month of 5 or 6 days.
The Hebrew Calendar is similar but weird in its own way. It has 12 months of either 29 or 30 days, and then 7 of every 19 years have a "leap month" of 29-30 days. So the years are either around 355 or 385 days.
And we would finally get "Checkuary" as a real month!
13 is a prime number, which is very inconvenient in calculus. it will be difficult to count half, third and quarter of year. All the quarterly reports will be fucked.
@@respise let's then work 10 or 12 months only 🤓
In Iran we have the first 7 months with 30 days and the remaining with 31. It adds up perfectly and you still get to keep the 12 system. Also, our New Year's is the 1st day of Spring! (in 2-3 days now) Much love
is that a modern thing or was it devised centuries back by the Persians or something?
Really? So, does that mean February has 30 days as well, of course taking the first month as of January, right?
@@JohnDoe-rk7ex I believe each month and each day has its own different name, not really the same as our western calendar ones.
By the way I wish OP the best Newroz!
Neat!
@@JohnDoe-rk7ex The names are different the starting days of months are different
When space travel becomes a reality, your code also need to handle relativistic effects on time. Luckily, I'm not a programmer -- so, good luck, and have fun, suckers!!!
*internal screaming*
Well, at least everyone should agree on causality.
Unless time travel is possible, in this situation we should just ignore that time is a thing.
We already do. GPS already needs to take General Relativity into account. Because, you know, clocks run slower down here than up there.
They already take it into account with GPS satellites.
"Every device has its own clock, so program according to each of these clocks"
- Someone smart who should've warned everyone sooner
Fun Fact: The current DST implementation goes all the way back to 1784, when the devil had 10 days to write this stupid idea.
I was really looking for a dateTime library for my project! That really helped
if you like alternatives to try I can personally recommend spacetime, been using it for years and the maintainer is very friendly everytime I either find a bug or would like to suggest a new feature
@@Mitsunee_ Thanks for the recommendation. I will definitely try it out!!
Have you bought the paid course of fireship?
@@YashCurious No, I am poooor!!
I wish more people would appreciate the insanity of daylight savings, timezones, and our calendar as a whole
Timezones are a practical evil.
DST are a bureaucratic "solution".
But our calendar? No excuse for that quaint Frankenstein mess. Only the year duration makes sense.
Can't wait for Mars timezones 🔥
I have to say I feel grateful right now for working with C# and its pretty decent System DateTime and TimeSpan classes. I do not envy whoever it was that had to implement those. To the unnamed microsoft developer who did this thankless slog of a job, so we didn't have to, thank you!
About Java, there was one more update to DateTime API with the new set of solutions called LocalDateTime which was introduced with Java 8(appr 2014), so we may say that Java's time is 2 steps ahead of JS' one, which is kinda weird according to JS popularity lastly.
I like how the modulus leftover is assigned as "rest day". I think we've earned it!
Lol
Yeah, looks simple, but how is that supposed to simplify time management? To enter a date, one have to select a radio button first that it is a rest day or a normal day, then when the latter, then which month and day?
On the reverse side, how the date supposed to be displayed?
It wouldn't actually solve the problem, would just make it complicated in a different way than we have now.
I always use UTC timestamps and format them locally on the user device. Usually this works fine. Still sometimes I face issues. - Thanks for the video!
Same, work mostly in bash/shell or similar level languages as opposed to JS or Python. I've noticed changing output formats to then do operations such as remove the start time from finish time to find elapsed job time to be finicky sometimes
This is the way.
I had this project where I was in lead where we had to do some predictive modeling based on measurement data. Fairly complicated system but we managed to implement it pretty easily.
When taking it in to production, time formats caused days of extra work and ended up being the most painful part of the project.
It's always in deployment to production where things randomly stop working. I learned that the hard way.
It's March 17 2022, thank you for letting me know..
This series is just outright amazing. Please keep it up.
Apart from timezone (which are a nightmare, whatever the thing you use), I really enjoy the way PHP handle date by default, and it's even better with library like carbon
Reminds me of Computerphile's "The Problem with Time & Timezones" with Tom Scott, also a nice video about this topic
Just in time. Today many rail steering systems (made by Alstom) in Poland (I also heard about Singapore, India, Czechia) has broken because of an issue in time calculation.
I really hate time and date in programming. It's a real pain...
It is the bane of a programmer's existence.
I’m loving these code reports!
Love code reports. Short, cool, informative, great.
What a good new format ❤
The good and the bad thing about the Temporal API is that it is fully compatible with the Intl.DateTimeFormat object. So this means formatting dates will be the same as before, just beware the wrapper call is date.toLocaleString(...) for pure dates (without time) as well. This is the good part about it. The bad is, the formatter's implementation for Temporals is even more limited in some circumstances, for instance you have to do manual formatting if you want to format historical dates with 4 digit years before the year 1000, etc. Not even the ISO formatting outputs 4 digit years for historical dates, but it did for the old Date API. I hope the formatter will get more work on it as well in the future. We really need a 4-digit option for the year as well.
If the one sacrifice to having reasonable dates is having to do a little extra work when working with dates before 1000AD I'm perfectly happy with that.
With constant length years you introduce the Y10K bug.
“The Earth doesn’t rotate perfectly, because it’s actually flat.”
I’ll assume that’s a joke, lol. It’s actually a sphere that’s slightly “squished down” from the poles, making it a geoid, if anyone would like to know.
So basically flat if you round it
And watching Jeff's videos is " Time not wasted ".
Your are constantly reporting the news for us.. Never ever stop doing these kinds of things..❤️
"Time is what you make of it". I'm glad I spent it on this amazing channel
Refering Nepal just made my day big fan and a student sir. Keep up the good work
This series is so good, I’d say it’s even better than the 100-seconds series which was already really good!
㈩➀➆➁⓪➄⓪➆➃➆➇➂
Can't wait for the 4/1 episode.
Great video as usual!
Ayyy! I've been developing this analytics pwa and date time functionality has been honest hell. Between comparing the ISO string formats to direct casting a format of (%b-%Y), having to check that against comparative millisecond times and then having to recast the incoming collection of DF handled by dask. It's hell because time is so abstract and the concept of dealing with it in a linear fashion just does not seem to compute or work well our current systems and design frameworks. Keep up the amazing videos my man, I truly love your content!
And you have nailed the reason that I keep all my servers, routers, etc, set to UTC. DST changes mess with logs, charts, etc.
@@javabeanz8549 UTC and fixed offsets of it are a blessing. I need nothing more and I'm not willing to accept anything else in a project under my control.
@@javabeanz8549 I'm thinking about just converting all known full dates to UTC and just dropping any irrelevant columnar data at this point, it's just too much to handle. I want to think about writing overly complex business logic that makes me --hard not date time nonsense.
Linux system logfiles used to use some idea of a “system” timezone for timestamps. Luckily, systemd does away with this: internally timestamps are stored as UTC, but you can display entries in any timezone you like, by setting your TZ variable in the usual way.
Was struggling with dates this morning. Temporal sounds amazing.
0:42 i was glad to my country there :))
About time somebody talked about this topic.
I enjoyed this video! Thanks.
Just had to write my own basic Date class as an assignment in class, and a big takeaway for me was calendar reform
I love these! Keep them coming
.㈩➀➆➁⓪➄⓪➆➃➆➇➂.....
the only news report i need
This is soooo weird… I was just looking into this exact concept as this video came out
I remember in school we had a project in 3rd semester that involved storing date/times and converting between calendar formats (gregorian, julian, hebrew, vulcan, etc), was not a project I finished XD
Reminds me of how I casually found a bug that remained silent in an Angular app for a couple of years.
Past january I've noticed a strange sequence of dates in a list of records.
Provided that the list was ordered by date, it went something like "28/12/2021", "29/12/2021", "30/12/2021" and so on...and suddenly: "01/01/2021", then: "02/01/2022", "03/01/2022", etc.
Turns out the date format for the year part was set to "Y" (uppercase) which represents the "week" year and, since January 1st of 2022 was saturday, it belonged, actually, to the last week of 2021 as defined by ISO standards and stuff, turning the year part to show "2021" and giving me a couple of hours of improper shouting and a big smile when I just found out!
could not have expected Nepal to pop up. Nice work, man!
I first thought this would be about imperative programming and how the value of a variable will depend on time which sucks hard
Love the Video. Moment JS is a lifesaver
Also you may want to make a emergency episode talking about node-ipc and the malicious payload included in it. Especially Since it's also used by Vue CLI
Do you know any articles that cover this matter in more depth? I'd like to read up on it.
this is the only news that still has integrity. good work guys.
Thank you for including Nepal 🇳🇵
Twice a year I miss one weekly meeting as we are in US and EU timezones and we change time on different dates and I just assume it's at the same hour without checking calendar....
Use the GNU “date” command to check:
ldo@theon:~> TZ=CET date -d "now"
Fri 18 Mar 2022 23:07:59 CET
ldo@theon:~> TZ=CET date -d "+ 2 weeks"
Sat 02 Apr 2022 00:08:01 CEST
papa franku is still remembered, love the thumbnail!
Bro it's crazy how I'm making a time series API today and you made this video lmaoo
In a c# backend we can use coordinates to knowing the current time for the required zone
Woow😮,
Fireship, when did you surpass a million subscribers??
I've been too focused on the videos and never saw your growth, happy for you man🤜🤛
Great stuff
I like the Bahá’í Calendar, with 19 months of 19 days each. Then you just have 4-5 intercalary days as an annual time of celebration (similar to Christmas break, but at the spring equinox). It feels very simple and elegant
Seems bizarre to choose a prime number for the length and number of months.
I often encounter this kind of problem when working on sale report, or other reports. Days of month are weird LOL
Brazil also doesn't have daylight saving time anymore, it was canceled recently, which made a lot of devices go crazy changing time by themselves
Love this series🤓
Great timing because I was just trying to compare date equality in JavaScript. It was a mess!
Awesome another Code Report 🙂
Thanks for adding Temporal mate, I pinged you in Twitter asking for a tutorial. Looking at this shows that you DO look at your Twitter and try to research as much as possible
Lot's of Love from Nepal 🇳🇵
I love this series 😍
I spent last 6 years on projects about time representation, some math with and, of course, all in js. My mental health has been badly injured.
Just when I'm planning to build a countdown timer for a project in React
Hearing own country name unexpectedly feels weird!! Love from Nepal
Luxon is an amazing library to work with dates & time in JS, it's so intuitive and simple! On a different note, for a second I thought you were going to talk about how time is our worst enemy because THERE'S NEVER ENOUGH OF IT. Guess it works both ways, though.
I'm surprised there wasn't a reference to Tom Scott's descent into madness during his explanation of time zones
I'm going to say this upfront, but The Code Report is yet another GOATed series by Fireship aside from 100 seconds. Godly content creator. You deserve so much more views.
Oh boy is it. The labs I need to program this week
the creation of the code report is the best thing ever happened!!
㈩➀➆➁⓪➄⓪➆➃➆➇➂
✍✍✍✍✍
i thought it's gonna be about this time related bug that stoped all trains in Poland today
This video came right after I fixed a bug with daylight savings with typescript. I can proudly say I found a working solution for me that day :D
Fun fact... there is a part of Arizona that does follow day light savings.
That JS joke at the beginning killed me
Awesome video .
Shout out for Nepal! Just happened to be sitting there.
There is also an Intl API that has something to do with date / time formatting also.
to make matters even more complicated, there are areas within AZ that DO observe DST. Time is hard...
Tom Scott has a great video about the same problem...
I like how fast paste your videos are
Having built numerous custom calendars, and scheduling apps, dates are definitely a headache.
Great video, Jeff! Can you do one on Unicode?
Use multi-date lib to handle date and time in js
This was the best birthday gift ever
Dealing with complex Time interactions is the only time I consistently reach for a library in JS. It’s just such a mess. Really hopeful for temporal object in a few hears.
I don't know if its the same in javascript, but in typescript, month 0 is january and other languages uses 1 for it
Man i gotta say i love the code report videos
㈩➀➆➁⓪➄⓪➆➃➆➇➂
Can you make a video on the chaos that is node-ipc. Please bring exposure to this ASAP. This is DANGEROUS
This guy makes my day... 😂😂
He makes programming seem a little more fun...
I was literally just working on a custom DateTime class for my project, because the language I'm using doesn't have one.
1:40 yoo my hometowns (prague) astronomical clock