Coding Blocks - Why Date-ing is Hard

Episode Date: March 18, 2019

We take a deep dive into understanding why all Date-s are not created equal while learning that Joe is not a fan of months, King Kong has nothing on Allen, and Michael still uses GETDATE(). Oops.

you're listening to coding box episode 102 subscribe to us leave us a review on itunes stitcher and more using your favorite podcast app and visit us at coding blocks.net we can find show notes samples discussion and more you know i sound the same at all speeds come on we've got to make it different send your your feedback and rants and questions to comments at Cody blocks.net. Follow us on Twitter at Cody blocks or head to dub, dub, dub. Cody blocks.net and find all our social links there at the top of the page.

With that, I'm Alan Underwood. I'm Joe. And I'm Michael outlaw. This episode is brought to you by Stella res, the AI powered talent agent for top tech talent. Hate your job or just kind of meh about it? Stellarez will help you find a new job you'll actually be excited to go to.

And Stellarez knows that a job is much more than how it sounds in a description. So they built their AI-powered talent agent to help you find your ideal job. Stellarez does all the work in screening for you, scouting the best companies and roles, and introducing you to opportunities outside your network that you wouldn't have found otherwise. Combining deep AI matching with human support, Stellarez pairs things down to a maximum of five opportunities that tightly match your goals, like compensation, work-life balance, working on products you're passionate about, and team chemistry. They then facilitate warm intros, and there's never any

pressure, just opportunities to explore what's out there. To get started and find the job that's just right for you, visit stellarez.ai slash codingblocks. That's S-T-E-L-L-A-R-E-S dot A-I slash codingblocks. Before we jump into the topic today, which is going to be all about dates and times and how hard they are in programming, the first thing we'd like to do is go over a little bit of podcast news. And first, we want to thank those who have taken the time to leave us some reviews. Yep. And so from iTunes, we'd like to thank MikeJG101, Javi Kroonenberg, Grumpfump sean finally left a review hippie mx uh krosling kip winger 777 and jamal zada that was that was pretty impressive yes like a boss and sean truly finally did leave a review. It's like two years in. We're proud of you, man. Thank you. So I've got Stitcher here.

Wait, were you going to do all of it by yourself? Because we got like a little bit here. Oh, yeah. We have a few. We want to switch them up. Me and Jay-Z alternate these. Is that what we want to do? Yep, let's do it.

All right, here we go. So I've got Amonor. Wait, no, I say Amonor. Yeah, it's going to be weird if he reads the next one. I'll go ahead and say the next one. Joe is clearly the best, which is awkward. Thank you, thank you. What do we got?

I think that's one that Joe wrote in, by the way. Because remember last episode, he said he was going to do that? He said, I'll just write anything in here and you'll read it. That's right. The Bugger-minator. Something vague? Yeah, there we go. Sergeant McClain. Autex.

WandaVie. Wait, come on. That's got to be VI. Maybe. Ooh. Code Irata. I like that one. Eric O. Brantley.

PB and Jamstack. That was Joe. Morton. Oh, God. Please be careful. This is you. Oh, is it me? Yeah, it's your turn.

Oh. Okay, so I'm going to say this in a Southern way. Super slow. And I'm going to say it slow. Super slow. Sofa. There we go. King.

Yep, yep. Pythonic. Yes, very nice. If you'd like to say that faster on your own, that's up to you. We made a decision here. Keeping it PG here. Yeah, keeping it PG. Also, I want to say a big thanks to Thomas for leaving

us a review and discuss. It was really nice and we appreciate all the great feedback. We just crossed episode 100 so I'm going to take a couple extra seconds to say thank you very much for all your help in getting us through like five years now. Six years. Crazy. It's been awesome. 100 episodes. Yeah man.

Insane. And coming up into March, we're all going to be in Orlando Code Camp. We've got a couple hats to give away. So if you're one of the early birds that comes up and asks for it, we'll give it to you. And we'll have a booth. We'll be doing a little panel there too. So make sure to come on by and

say hello. Get Alan in the shins. Now, wait. Now, question. Should the hats be given away just because they asked? Or should we make them have some fun with it? If you can kick Joe in the shins and we can verify it, it has to be verifiable, then you get a hat. Yeah, I think that's – I like the first way better. Wait, what?

Oh, where they just ask? That sounds kind of boring. I guess we'll do it that way. Yeah, I've never seen anybody do it, even though he's asked a lot. Hey, and in fairness, hey, Santosh, I did find what my talk is on. I think I'm good now. I was able to log in and I was able to see it. So I'll prepare at least something for Orlando Code Camp. That'll be fun.

And I wanted to mention this. I don't think Joe was going to put this in here but he actually wrote a nice little article about the the myth of full stack developers and how he he disliked some of the negativity around it so we'll have a link in the show notes for that and i think that's worth reading it's a good stuff there yeah i'll tell you real quick um sorry about the version but when i first started programming like the web was new and I was like a young kid doing HTML and like all the like the real programmers were kind of turn their nose up at HTML

and so I kind of had this chip on my shoulder back then that like I kind of felt like I wasn't a real programmer and so like I started focusing more on back end stuff you know I wanted to be a real programmer they still never really quite like looked at me the same as like the real programmers and then at some point in my life at some point in my career it kind of changed so i started working on some

more back-end stuff and i started kind of getting attitudes like oh man you only do back-end stuff like that's easy like try working with humans sometimes and i felt like people were telling me again like nah now you're not a real programmer because you're not doing much web stuff like what the heck and i feel like throughout all our, we've probably heard the same kind of stuff like, well, engineers have to build bridges that are mission critical and can't fail, and programmers just slap stuff together. I just feel like

I'm tired of the gatekeeping. I'm tired of people telling other people that they're not good enough, that they're not real programmers. Listen, if you're solving problems and you're doing good work, don't let anyone put you down. Don't let anyone put anyone else down. And, yeah, there's my high horse for the episode. You know, there was an interesting tweet.

Now I can't find it. So I could have sworn it was from Arlene that tweeted it. Or maybe it wasn't a tweet. Maybe it was a Slack message or something that saw it come in. But, you know, we talked about, like, you know, you know the idea of like being a t-shaped developer right you remember that conversation and i think i've jokingly you know said about just being like a a narrow dash before you know um but she or someone made the point of saying like referring to full stack developers as a lowercase M-shaped developer. Because in specifically a lowercase letter because there weren't like high peaks and valleys between it.

But the point being is like there's a few things that you can go deep on, right? I agree with that. I thought that was a neat – I thought that I liked that, uh, that concept. I agree with that. I also, I mean, I know we don't want to go on this too long, but it is kind of annoying when people are like, Oh, um, Jack of all trades, master of none. I feel like that's complete garbage because if you've been doing it long enough, you're probably very skilled in a couple of those areas. Right. And then you, and then you probably have a decent amount of knowledge, even in the other one that you

wouldn't consider yourself an expert in. So a full stack developer is real. I know lots of them and it's, it's actually really hard. And I'm not saying it's easy to be somebody that's just, you know, super, uh, deep in one particular thing right like there's there's merit to all of it but a full stack developer is not a myth right if somebody can take something from soup to nuts themselves with little to no external interaction that's full stack so but if you google full stack the first article is called full stack developers are a myth yeah complete garbage oh yeah you can read the article and then toss it away yeah so anyway nothing wrong with specializing but there's nothing wrong with uh going wide or being a

full stack or being able to do whatever kind of stuff that you do totally that was the point with that talk to the derail no no all good okay so this this particular episode put on your propeller hats there's the man like there's way more complexity to dates and times encoding wait dating yeah see dating is hard is that what we're talking about dating can be hard or it can be fun. I guess it depends on your approach. But why are we even talking about this? I guess it would be the first question is, come on, a date's a date, right? Like I just say new date and I have my thing.

Or in C Sharp I can say datetime.now and I'm good, right? Well, no. So in case you didn't know, people live across time zones, right? Like I'm a big fan of Monday night football. And it doesn't start until 930 my time where all the people out in California are watching it during the regular waking hours, right? That's a problem. So there's this thing of different time zones. And there's, man, there's so much with this.

One of the first things that I have is, I said, let's paint a picture. Go ahead. Well, I was going to say, like, can we maybe back it up? Because it almost sounds like, like, obviously we're all aware of time zones, right? But you think that that's all you need to worry about, right? Like, you know, you think like, oh, there's nothing to dates, right? Like, you know the time zone and you're good. Yeah.

So let's paint the picture of starting there, because that's the premise that, you know, the time zone and you're good. Yeah. So let's, let's paint the picture of starting there. Cause that's the premise that, you know, most people are going to think. Yeah. So let's say that you log something in an application on February 28th, 2016 at 10 PM in California, which is Pacific standard time, right? 2016 happened to be a leap year. So people from different parts of the world use this application. All right. People from all over the world, different time zones. How should this show up for someone on the East coast in the U S was at 1 AM on February 29th? No, didn't February 29th is a leap year. So yeah, maybe it should be that. Do you show it in the original time that it happened, right? Maybe there's another time zone that you prefer to see everything in.

Do you care if it shows the time of the day that it actually happened where it was, right? There's all these weird questions that come along for the ride because the thing that you might be looking at, did this happen during working hours? Well, working hours in that part of the world, yeah, maybe. If it was that time of night, probably not. But would it have been working hours in your part of the world? No. I mean here's a thought that you didn't have here in this specific example. So it wouldn't apply to this specific example, but if you had picked, say, an August 28th at 10 p.m., then you'd be in daylight savings times.

So if you were trying to show this thing relative to the person so that they would see in their own local time, then you got to take into account, oh, well, does this locality take into consideration daylight savings time or not? And that widely varies. And Arizona doesn't, right? Yeah, there might be portions. But, I mean, there's even parts of the world that have changed over time, right? Like that have said, oh, now we don't do daylight savings time, but we used to.

Well, check this out. What time zone are you in right now? You're talking to me? Yeah. Eastern. No, he's asking me. Eastern. Eastern. Eastern time.

Do you mean generalized Eastern time, Eastern standard time, or Eastern daylight time? Right. Because your time zone actually changes based on the calendar year. So it's not that we move the clocks ahead. We actually change to a different zone, at least here in the states, particularly in our states. Right. So right now we're in Eastern Standard Time, but in a few months we're going to be in Eastern Daylight Time. Eastern Daylight Savings Time, right.

Those are both differentiated from the generalized Eastern Time, which is only one of those. It's absolutely crazy. So some of the things you have to think about here is how do you store the information, right? That's a big deal. How do you know how to display it back to the users of your application? Like I said, are you giving them the ability to choose the time zone? Are you telling them, show it in the time that it occurred at that location? There's all kinds of things. But here's the key part, at that location, like there's, there's all kinds of things, but here's, here's the key part, at least for me was knowing what your application needs and what

it's doing is probably the most important part, right? Like if you're using a security application or you're writing a security application, it's important to know that things happen during the standard hours of business. Like I mentioned, right? Like if it was between 8 and 5 in Eastern Standard in Georgia, right? If somebody is working in a call center or in a security center overseas in Great Britain, they want to know if something happened during business hours where that event was logged, not whether it happened in their time zone during business hours, right? So the context of this date and time is super important. So I don't know. I want to mention too, there's a bunch of tricky stuff with weeks.

Like if you ever had to deal with anything that's like the first week of the year, well, when is that? Is it the first Monday? Is it the first monday is it the january 1st is it the it just gets really weird and and some weeks or some years are longer than others and there's even leap seconds so things get really funky when you start thinking like wait there aren't always the same amount of seconds in a day it's absolutely nuts and you'll find out that a lot of times when you're talking to, and we're going to dig into this really deep, but when you start talking about things like, uh, epoch times and whatnot, a lot of times those

skip the leap seconds, right? Like they don't count them because it's just too hard to do. So it almost sounds like as a general rule though, based off of some of the things you already said that you, you pretty much want to favor the side of storing as much detail as you can. Because if you did want to have, like, different use cases where, like, maybe on one screen you want to show it relative to the user who's looking, you know, the user's time zone who's reading it versus, oh, here's the chronological actual time, you know, you're not going to, you can't go back and undo that if you don't have it up front.

Right. Having the extra data, if you can afford it, makes sense. If you can afford it, that's a key thing. Yeah. So the first thing I want to start off with before we dig into implementations across the different layers that we're familiar with and the most familiar with is a standard that exists. This is a light reading from Wikipedia. And it reads, ISO 8601, data elements in interchange formats. Man, look, familiarize yourself. If you're doing anything in applications, familiarize yourself with ISO 8601.

And what you're about to find out is it's way more complicated than what you would have ever thought a date could be. I really feel like we could do a reading of this article and it would be hilarious if we all did it in like NPR fashion, very monotone. The history of the world type stuff. Interchange information. Like the first minute would be funny

and then like the middle, like two minutes to four hours would not be funny. But maybe it gets funny again at the end. Depends on who the sponsor is. It's pretty big. So here's the crazy thing. You see when this thing was published? 1988.

So only 88 years after we started even being able to track dates. Have you ever seen SQL Server? The earliest date you can do in their date field is 1900. Well, yes, but no. Yeah, we'll get to that. So here's the crazy part. 1988. So software development has been a thing for a while.

We're in the year 2019 and this stuff is still hard. Like that's crazy when you think about that. So here's, here's a couple of rules of the ISO 8601 standard that I think are, are pretty easy to grasp. So the date and time values are ordered from the largest of the small unit of time. So if you think about it, if you wanted to be able to order things via like a text thing, you're going to go year, month, day, hour, minute, second, and then the fraction of the second. So that's pretty easy to see. And that's a standard format that you'll see in a lot of places. Which is great for files.

It's fantastic for being able to sort files, right? Yeah, that's the, that's what I always use. I mean, I don't care about those nanoseconds or whatever, but I like definitely like year, month, date. Yeah. It's helpful. Uh, so here's another thing. Each date and time value has a fixed number of digits that must be padded with leading zero. So that's important, right? Like you can't have 2019 dash one. It's got to be 2019-01. Right. Again, very helpful for file names.

It really is. Because if you had one and then you had a 10. Right. October and January would be sorted the same when they shouldn't be. Right. So representations can be done in one of two formats. And this is kind of weird to me. Like I didn't know this was part of the standard, a basic format with a minimal number of separators or an extended format with

the separators added to enhance human readability. So basically what they're talking about is when you have like 2019 dash, you can get rid of the dashes. When you have the hours, minutes, seconds, you can get rid of the colons and the, and the decimals. So you can do the format with or without these things. I prefer it with it because again, it is human readable, but as long as you work with the ISO 8601 standard, you can do it with or without. Oh, it's 24 hours, right? 24 hours. So zero to 23.

Yep. Yep. So for reduced accuracy, this part, this is where things just started going crazy in my mind. Any number of values may be dropped for many of the date time representations. So if you just want to talk about January 2019, you can do 2019-01, and then that's it. You can truncate the rest of it. If you want it to be the first day of January 2019, you can do 2019-01-01, and then drop the rest of it. You can truncate the rest of it. If you want it to be the first day of January 2019, you do 2019-01-01 and then drop the rest of it. So you can literally chop off the date, time, stuff wherever you want. So 2019 is valid 8-6-0-1. I saw 8-6-0-1.

Yes. Just the year. Yes. But it has to be from the least to the most significant, right? So I can't chop out one in the middle. Right. Or I can't chop off the year. Right.

You have to start at the year, then go month, date, et cetera. Right, so most significant to least. Yeah. You said that backwards a minute ago, right? I think they said it – I think they wrote it wrong on here. Because you said least to most, and that kind of threw me. Yeah. The least value, like the year is the biggest. Oh, but in the order of least to most significant and that kind of threw me yeah the least value like the year but in the order

of least to most significant so wait well well yeah so you can only remove the least significant yeah the values may be dropped there okay so they're referring to the order but when joe asked his question he was keeping the significant that's what threw it okay gotcha yep so if necessary for a particular application, the standard supports the addition of a decimal fraction for the smallest time value in the representation. So that's an interesting thing is I don't think, you know,

it is the smallest time value. So it's a second. So you can start doing fractions of seconds after that. Oh, wait, I thought they were saying the smallest fraction that you're adding on there. So if you did in 2019, you could say 2019.5.

So I don't know. Maybe it is. Was that in the... The smallest time value in the representation. So yeah, I would think you could do 2019.5. You might be able to. Which would be somewhere in the middle of the year. Yeah. Good luck if you could never do that.

I'm not saying you should. I'm not saying you should. I'm not saying you should. But the standard allows for it. That's the standard, right? Yeah. All right. So we're going to break this down and talk about the various different pieces of this because this is where things get really important. So years in the 8601 format, it has to be a four

digit year to avoid the year 2000 problem. Like, because if you have zero, zero, what is that? Is that 2000? Is that 1900, 1800? You don't know. Right. Um, and that, that makes sense. So here's an interesting thing though, to represent the years before zero, zero, zero, zero, or after nine, nine, nine, nine, the standard permits for the expansion of the year. If you agree with it, with the people that you're interchanging data with, with a plus or a minus sign. So if you do a minus sign, that's before the year, zero, zero, zero, zero. If you do a plus sign, then it's after. Now, the part that's sort of weird to me is it says by convention, 1 BC is labeled plus 0000. I have no idea why that makes sense.

But 2 BC, so two years before 000000 is negative 0001. Well, I guess they're making the distinction that the year one, so 0001 would be the first AD year. So zero had to be something. Well, I think though. So they picked it as being the first of the BC years. Well, I think they're trading it like time though. Because if you have 0000, that's literally the year of 0000. But if

you want it to be negative one, it's just plus 0000, which is sort of mind-numbing to me. No, no, no. There's not a 0000 and a plus 0000. You don't think so? That wasn't my interpretation.

I don't think so? That wasn't my interpretation. I don't know. I know that it says for 1 BC, you have to put the plus. And for 2 BC, you have to have minus 0001. Well, they're saying that by convention, it's labeled as plus. Not that you have to have it. But the 2 BC, because it's going backwards, you have to have the but the 2 bc because it's going backwards you know you have to have the negative there but it's one it's a one offset which is what's really bizarre and again that's what i'm saying is that like there is no year zero right so they had because they were

using just the number system to represent this, then they needed, they weren't going to skip the zero. So the zero had to be something. So you either make zero the one BC or the one AD, and it was decided to make it the one BC. Yeah, it's really bizarre. Bless you. Sorry. So don't let it happen again. That's years. For the most part, you may never actually have to deal with this, right? Like in the year part, you may not ever have to deal with it, but the standard has stuff in there so that you can go crazy positive or negative. All right. Round table real quick. How many applications have you written where you needed to do calendaring back to 1 BC? Yeah. I was just wondering, like, if you ever have worked with dates before even 1900, I would love

to hear about it. So you should leave a comment or send a tweet or something. I would really like to know how that worked out and what kind of stuff you ran into. I mean, honestly, I was trying to think of what would be possible use cases where you might not. And the things I was coming up with would be like, okay, maybe you're writing applications that can scroll back through dates in history, right? And so you're know, you're letting the user pick a particular date and then you can go back to it. So like a – think of something like a Wikipedia, right? And you're like, hey, what happened on this day, you know, 300 years ago?

Or, yeah, or like star-related, you know, astronomy kind of thing. Yeah, like, you know, trying to like figure out like, Hey, what was the rep? What did the world look like back then? You know, like historical things that was, there was no other thing I could think of where it was like a valid use case. Yeah. Like I'm not going to go to stub hub and be like,

Hey, I want to buy tickets for the Metallica concert 500 years ago. I mean, right. Is sequel server still going to be a thing in the year? 99 99. Oh, that was another thing was like hey are we setting

ourselves up for a future you know like whatever the y2k version of you know it'd be like y 10,000 you know well we all worked in a system where the uh the max date that they used was 25 25 i remember that oh that was awful dude in the year 25 25 now i mean technically to to answer my own joke about that you know setting it up for the Y10K problem. Technically, the answer is no, because the standard does account for it. It does account for it. You put a plus on that thing. But that was still weird, though.

It was like, why did you make an arbitrary decision that, like, it can only go up? Like, why can't you make it go more? Well, why not just have five digits and force it, right? Or six? Yeah, I feel like we're doing, like, a six-minute ab commercial, you know? why can't you make it go more? Why not just have five digits and force it? Right. Or six. Yeah. I feel like, I feel like we're doing like a six minute ab commercial, you know,

seven minutes. No, no, no, no. Yeah. It was like, why,

why, why limit it? You know? Yeah, I agree. Like it feels like they put some arbitrary garbage on there just to make it to where to enforce it. But it would have been so much easier to just say,

Hey, we're going to make this six digits and you're going to left pad it with zeros i mean because let's be honest a hundred thousand years from now people are going to be so mad at us for coming up with this stupid standard that's based on four digits and they got to do a plus sign they're going to do but they're going to up the standard and it's going to be plus 8601 so that's that's what's going to happen. I can see people doing stuff now. Like astronomical is a good example. You say like, you know, when is Halley's Comet going to fly by in the year 10,000?

That would be kind of nice to know. Maybe, but isn't the sun going to burn out by then? I don't know. All right. You got to be more optimistic than that. I mean, don't be so pessimistic. It's going to last. The year 20K. All right. You got to be more optimistic than that. I mean, don't be so pessimistic. It's going to last. The year 20K.

All right. So the next one up, this one's probably the easiest one. And the one that makes the most sense is just a calendar date. It's basically what you'd expect, a two-digit day representing the day of the month. So 01 through 31, right? Like that doesn't get much easier. That's about as easy as it gets here anyways. They try to do math on it. Oh, yeah, that's doesn't get much easier that's about as easy as it gets here anyways they try to do math on it oh yeah that's true too you're like 15 days past uh january 18th

oh man now that's where you're not even talking about representing the standard here that's just crazy stuff that's that's date math and that's scheduling is so hard it really is it's so easy to go wrong like i i advise never writing your own scheduler if you go yeah or write a calendar you'll you'll give up on life i actually have a good tool that i use for that oh yeah well i don't say like tool would be like sequel server man no no well because i don't i might not have access to a sequel server or you know ss uh sequel server management studio but you but you can just go to timeanddate.com and you can plug in like, hey, this date, and then add 17 days to it and it'll roll over

the months for you or 67 days or whatever. And then that way you don't have to worry about it. You can also ask Alexa. You could. But she might give you a good answer. Yeah, but that or you're going to get something purchased. Yeah. Buy it on this date?

Okay. Just purchase 67 rolls of toilet paper. All right. So here's the next one that's kind of interesting, and this is week dates. So capital W, lowercase ww, is the week number prefixed by the letter w. So if you put w01 or anywhere through w53, then you're referring to one of the 53-ish weeks of the year. I know there's 52, but this is a standard they have to accommodate for what Joe said earlier, which is how do you know what the first week of the year is? Right.

So going with this, where did I go? Real quick, before you do that, though, did anyone else kind of have flashbacks to the opening of the show and kind of think that when he was saying like uppercase W, lowercase W, lowercase W, like you were making a reference to how you would say our website. You could, you could. Calculated. Yeah. So here's the crazy part. You can put a D after it as well, or not a D. You can put a digit in there for the day after it,

and that'll represent the number from one through seven, beginning with Monday and ending with Sunday. So you could have the format of capital Y, Y, Y, Y dash capital W and then lowercase W W or you can do capital Y, Y, Y, Y, all caps dash capital W lowercase W W dash D D being the day of the week. So you can literally say, Hey, I want your 2019 fifth week, third day. And that's a way to represent these things in the ISO standard. That's how I like to do my cron jobs. Oh, don't even get me started about the cron scheduler.

I'm just joking. I was thinking, if you would ask me a week ago if some system supported AD601, let me see an example and you would show me example like yeah we totally support that and obviously i like whatever i'm whatever code i've written around dates does not support all those crazy w's and d's and like scaling precision and pluses and minuses you have any regular expression you've ever written that does parsing for dates i I guarantee you got it wrong. Dude, that's the one step below emails.

That's the one thing that's really frustrating. And we'll talk about more of it when we get to the C sharp stuff. But even C sharp doesn't have the 8601 standard built in is just something you can go use. And it's like, man, if this is the standard that basically the whole world has said, hey, if you're on the Gregorian calendar, use it. Why do languages not have some native support built in for it, right? It's sort of infuriating. Yeah, I was dealing with some date stuff this week. And the format that I needed and the format I had was off by a Z, which every day.

So I literally had to go and add a Z onto all of my days because there are UTC. It just happened to like two different platforms. They kind of things just a little bit differently. We're going to make it happen here soon. Yes, we will. But it's frustrating. So here's one of the things that's interesting. So he asked about the first week, right?

Like what's actually the first week of the year? The week with the year's first Thursday in it. So weird. I guess because it was just past the midway point. I don't know, but that's it. Or it can be the week with the 4th of January in it. So either or. Either or.

It could be the first week with the majority four or more of its days in the starting year. So if you have four days on that first week, then, then you win, uh, the week starting with a Monday in the period of 29th of December through January 4th. That's also could be the first week. And so they give an example here as a consequence. If the 1st of January is on a Monday, a Tuesday, Wednesday, or Thursday, it is in week one. If the 1st of January is on a Friday, Saturday, Sunday, it is week 52 or 53 of the previous year. So it's more December than it is January. Let's just give it to last year.

It's crazy, man. But I mean, it kind of makes sense, right? Because it's not like your weeks just end at the end of the month. They continue into the next month. So,

but it's such a backwards way of thinking though, because like if you, okay, let me say if I, cause you know, maybe, maybe you would think about this different. If I were, if I were going to create, let's say I'm starting from scratch. There's no,

there's no standard already. There's nothing. And I'm saying, okay, we're going to, I'm going to start counting the weeks and I'm going to start from the beginning of the year, which is January 1st. And so there's week one. And then I'm going to start counting week two, week three, week four, week 52. Right. And then, you know, that that's where I'm going,

but this doesn't, it's like, it's more like it because there's a statement here about December 28th is always the last week of the year. Right. So it's almost like it's, it's backwards from the way I was thinking where other than like having a hard set rule of where the beginning is, there's the hard set rule of where the end is. Yep.

Yeah. So you'll never have a week 53 in a year, according to 806.01. No, you'll have a week 53. It's just saying the date of December 28th will be the last week. So it could be 52 or 53. Okay, okay. But it will always be the last week. So it could be 52 or 53. Okay. Okay. But it will always be the last one. So if, so if December 28th falls on week 52, there will be no 53. So yeah,

it's, it's, it's crazy, but be aware of this stuff because if you're ever having to implement standards where you're communicating between applications, ISO 8601 gives you the best ability to do it to where both sides of the application will understand what's going on. Yeah, it just reminded me. Do you know when the next leap second is?

Now? No. No. It might be in 2020. They haven't figured it out yet. Oh, that's good. Like, we're not sure yet. We got to kind of measure and see how it goes. The problem is that the atomic clocks are too good, and the Earth rotating around the sun is not quite precise enough to keep up with our CZM 133.

That's ridiculous, man. Oh, man. All right. So the next thing we want to talk about is ordinal dates. And I'm trying to remember what this was. So this supports the day of the, oh, that's right. This supports the day of the year without a month. So you have 365 days in a year or 366 on a leap year. So you can specify the day of the day of the year in the format with

four digit year and three digit days. days again has to be padded with zeros so if you're on day one it's zero zero one so for instance you could say 1981-095. That's April. I'm fine with that. So, you know, good stuff. This format is used with simple hardware systems that have a need for a date system, but where including the full calendar calculation software

might be a significant nuisance. It's kind of interesting to know that. I guess it's like a simple thing, right? I'm down with that. I hate the months anyway. It just don't make any sense. What are you talking about? There's not even an alphabetical order. And like, if I say like, April to me means something completely different to someone in the Southern Hemisphere. Like someone in South Africa, April means very much. So there's no sort of context that you get from like saying the month.

You know, just, can we just please just say the number? Man, you're crazy. Wait until we get to time zones again. I'm going to tell you all how it is. Yeah, time zones are going to mess everything up. All right, so the next big one that we have up is actual times. So the basic format is hours, hours, minutes, minutes, seconds, seconds. You can separate them with colons if you want, but those are the – and again, you have to include both digits, right?

The hour, hour refers to zero padded hour between zero and 24. 24 is used only to denote midnight at the end of a calendar day, and this gets important. And we'll talk about why in a second. The minutes is also zero padded, and it's zero through 59, right? It should make sense. If you hit 60, you're actually back at zero, zero for the next hour. Second seconds refers to padded seconds between zero and 60. 60 is only used to denote a leap second, which is what Joe was referring to previously.

So in almost every case, you should never see a 60. And I honestly don't even know when those leap seconds come in. So I think I got something interesting here for you. Sorry. All right. I've been trying this. So if I got this right, I'm going to back up for a minute. Going back to the week number thing.

So we said if the 1st of January is on a Monday, Tuesday, Wednesday, or Thursday, right? Uh-huh. Then it's in week one. Right. So, and I think day one, we haven't gotten to that yet, but day one, I believe, was Monday, right? Yes, day one is Monday. So, meaning that if the day number is one, two, three, or four, then, so if it's four or less, then it's week one. So, here's a little interesting bug you can go try for yourself.

If you were to open up a Google spreadsheet and you create a range of dates, and for me, I had to start at 1-1-21. And there's two functions that you can use. One is called weeknum, and then the other one is weekday. And you could pass in the other column to get the week number or the weekday number, right? You can see that for the year 2021, Google is wrong

and thinks that January 1 is the first week of the year. Well, maybe they're just not 8601 compliant. That could be possible. Well, that's what I'm saying. Yeah. Well, maybe they're just not 8601 compliant. That could be possible. Well, that's what I'm saying. It looks like nobody is. What I'm understanding, though, is it would either be a 52nd or 53rd

only in ISO 8601. Yes. Sorry. In 8601. Which is the way everyone thinks. Let's be honest. Of course it is. I mean, we all were before we even did this. I was just reading up on leap seconds. Apparently, they decided to start doing this in 1972 when they realized that they were 10 seconds behind.

But they didn't just want to add 10 seconds somewhere. It's like, oh, man, we got to spread this out. So, they picked a couple of days in the future. Like, we're just going to add some seconds here. And now, like, every once in a while, they just kind of stuff one in where they kind of made sense to like keep things, keep things regular. Are you serious?

27 leap seconds since 1972. 27. That's it. That's it. But 10 of those were kind of catch up. So that, you know, we got a lot more leap seconds back then than we get now.

That's ridiculous. I mean, accounting for a second, 27 seconds over, what would you say? 1971? That's ridiculous. I mean, accounting for a second, 27 seconds over what did you say? 1971? 1972. 1972 over 40 almost

50 years. Like really? Is it worth it? Let those seconds go. And that's why. Actually, I'm looking at two clocks right now. Like one's the International Atomic Time and the other is the Coordinated UTC Time. And right now the minute is different because these leap seconds. That's funny. And I don't know if they're still trying to catch these up or they're trying to get these in sync or they're just living within being in like 30 seconds out of sync.

That's ridiculous. That's pretty funny. Oh, yes. So, the International Atomic Time is 37 seconds ahead of UTC. Wow. 37. Interesting. Until the next leap second. And we'll be talking of UTC. Wow. 37. Interesting. Until the next leap second.

And we'll be talking about UTC shortly too. So the seconds we got the leap second, that's ridiculous. So the midnight thing, this is where the special case comes in that we were talking about with the 24 and the zero zero. So midnight can be referred to either as zero, zero,

zero, zero, or it can be a 24, zero zero zero. So midnight can be referred to either as zero zero zero zero, or it can be, uh, 24 zero zero. Now depends on which episode of Jack Bauer you're watching. Chloe. Uh, so, so, um, we need to pour open on the firewall now. That's right. Send it over to my pack. So here's the deal. Zero, zero, zero, zero refers to the beginning of the day. If you use 24, zero, zero, then it's basically referring

to the beginning of the next day. So if you use that time with a particular date, then you're actually talking about tomorrow. So be aware of that if you're sharing times and whatnot with different applications. Wait, say that again. If you're using zero, zero, you're talking about from the beginning of the day of that if you're sharing times and whatnot with different applications. Wait, say that again.

If you're using 00, you're talking about from the beginning of the day. So if you said today January – or let's just say it was January 1st, 0000, then that's the beginning of January 1st. That day. If you say January 1st, 2400, you're actually talking about midnight of January 2nd. You're talking about the start of January. You're talking about the end of January 1st, 2400, you're actually talking about midnight of January 2nd. You're talking about the start of January 1st, but the beginning of the next day. I just wanted to make sure. Even though they both refer to midnight, one refers to midnight, the end of the day, the other one refers to midnight, the beginning of the day. You know, am I the only one that ever gets confused? Like if you want to write something

like, you know, like, Hey, is that an AM or am or a pm like you know no you're not the only one and instead it'd be like you know what i'm just gonna write midnight or i'm just gonna write noon and forget about or i'm gonna be like hey i will call you we're gonna start that meeting at 1201 p.m i do it i do it yeah because now i know but i did the rule is definitely 12 p.m. is noon. Yeah, I know. But still, yes, you go through the middle thing. You're like, wait a second, is that right? Is it a.m.?

It was just a.m. No, I don't know. It's always a double take. Oh, man. All right. So the last little bit on this, let's see. Midnight special case, same instant, blah, blah, blah. All right. So decimal fractions can be added to any of three time elements. bit on this let's see midnight special case same instant blah blah blah all right so decimal

decimal fractions can be added to any of three time elements however a fraction may only be added to the lowest order time element in the representation so what we were talking about earlier if you add it to seconds you can do that but if you have seconds on there you can't do it to the minutes right if you're going to have just minutes and then truncated after that you can put a fraction on the minutes otherwise you do it the hours etc, right? If you're going to have just minutes and then truncate it after that, you can put a fraction on the minutes. Otherwise, you do it to the hours, et cetera, right? So that's all good. So going back to our earlier example of 2019 and a half, you can only do a half if that's the lowest – that's the smallest unit in your time.

Yes. Like the least significant. Yes. Yeah. They have some weird stuff here so what do they have a decimal mark either a comma or a dot without any preferences stated in resolution 10 of the 22nd general conference cgpm because that's important in 2003 right whatever uh you can use a decimal or comma basically. And if you want to do the fraction to denote 14 hours,

30 minutes and one half minutes, do not include a seconds figure represent 14 colon 30 comma five or 1430.5. So you can do all that. So yes, you, you can put fractions in there. I'll tell you 1988. This was some kind of convention. Dude, could you imagine being one of the people sitting on the board like, can we go home, please?

Man, they were partying like rock stars. Are you kidding? People were like, well, we want to call it zero. Well, we want to call it 24. We're like, fine, both, next. Exactly. Whatever. Moving on.

We want commas. Yeah, I don't care. Yeah. We want that. Okay. Yeah. So this is care. We want dots. Okay. Yeah. It's a problem for our children's children. This is where things get interesting to me is these time zone designators.

And this is where kind of a lot of the pain and dates come around. So time zones in 8601 are represented as local time with the location unspecified as UTC or an offset from UTC. Now I read an entire article on UTC because it doesn't make any sense. It's called coordinated universal time. So cut, right? Why UTC? And the article, I don't know if it was real. I don't know if it was legit or not, but it was entertaining. Basically, different countries around the world were like, no, it's going to be called this. And they basically came up with UTC as a way to compromise between all of them. Right.

But coordinated universal time is what it stands for. So the offset of zero, I feel like there should be like a OCD joke in there, you know, like it should be like CDO, but it's not, you know, and that's like something here too is like,

you know, your OCD is like, no, it should be CUT. It totally should. It's, it's ridiculous, man.

So, and then the funny part is it's always hard for my mind to rewind and go, wait, no, it's coordinated universal time, not time coordinated. Yeah, whatever. So here's the thing. If no UTC relation information is given with a time representation, the time is assumed to be in local time. This is super important. So if you had 2019, Oh one Oh one, and then you had 12 Oh one and zero seconds, it's going to assume it's in local time. Now that assumption is based off your computer configuration stuff,

right? So if I'm in Eastern standard time, like, like Joe pointed out earlier, it could be daylight savings. Time could not be whatever doesn't matter. It's assumed to be in the local time of the system that created that timestamp. And you have no idea what it is.

No, no, of the system that's reading the timestamp. Oh, of the system. So both who's putting it and reading it. Yeah, whoever's consuming it, they're going to assume it's in local time. Yeah. But they're not going to know what the real time that it was. It could have been in another time zone. And that's why this is so important.

Yes. Because if you write that without that time zone, how do you interpret it? Yeah. So you're just defaulting to, well, I guess it's my time. And I'll give a perfect example of where stuff like this can really bite you if you've been doing database applications for a long time. Or not. Or not. Or if you've been doing database applications for a long time and we're going to get or not or if you haven't whatever but when you go to store a date let's say that your server where that thing's being saved is in pacific time it's it's over on the west coast but your application that consumes that stuff is on the east coast

you now don't really know unless your application wrote that code or if you know the server wrote the code. Was it the client app? Well, if you have a database default constraint on a table, if you have a default constraint on a table of a get date, then that's going to be where the server is. And with the cloud, it's more likely than ever that your database isn't in the same time zone.

You may not even know where it is. Right. Right. If it's in the cloud, that thing could be in Europe. It could be here. It could be under your desk. You don't know where it is. Or there could be multiple instances of it in multiple time zones.

And one thing I want to caution here, and this is, I mean, I would love for you guys to chime in on this. If you're storing dates, pick where you're going to create that date from. Don't do some of them in your database and then do some of them in your application. And then some of them on your client app, you pick one and you make it the source of truth for how those dates are generated and saved. Man, that's a tough one. I like that. That's it's so dangerous because if you have your application server sitting in one time zone and your storage, your database server in another time zone, and you have different parts of your application saving these dates, one's being

generated from your database, the other one's being created from your application, and you're not storing those time zone offsets, you have no way to reconcile those things. But we all have like, we all think we're doing good by creating that default constraint that I just mentioned. Oh man, we're going to get into that. You think you're doing yourself a favor. Yeah, you think. But now you make a strong point, like you really shouldn't. And especially like, you know, I mean, not that this is necessarily where we're going with it, but if you want to ease your ability to horizontally scale, then you want your data tier having as little logic as possible, which includes something even as simple as a stupid date. Or we'll get to how you could do this better. So, Joe, you had something?

Yeah, I wanted to mention something. I remember one of the first times I set up a computer, I had to pick my offset. And back then, I didn't know. So, I was like, well, let me try four. That doesn't look right. And then go back and change it. But then, more recently, I keep seeing more and more the times when we'll have you kind of pick the city designation.

I kind of thought that was weird. So, for us, we picked New York because that's where we are. But I recently learned that there are actually some official designations that have those labeled. So if you see like Los Angeles time, that's not just them saying like this is the time zone that Los Angeles is in. That's an actual like official designation that maps to the Pacific time. And that kind of – it helps people get around the whole like, well, is it EDT or EST or is it – which one is it? So you just kind of say like I'm with that city and let's just leave it at that. It's absolutely nuts.

So let's dig into this coordinated universal time real quick, the UTC stuff. So if you have the date and it goes all the way down to your hours, minutes, seconds, whatever, If there's a capital Z at the end, then that indicates that the time is in UTC time. What UTC, the coordinated universal, we should back up here. That's basically a zero offset. And it's basically the time zone that goes over Great Britain, because I guess that's where the sun sat or set and ended on the entire empire, right? Yeah. So the UTC coordinated time, if you look at that slice on the world, that is your offset.

So basically, if you say it's midnight UTC, then you can go all the way around the world and you can say, okay, in Georgia where we live or in Florida where Joe lives, that's minus five hours, right? So depending on time of year, depending on time of year, but let's just assume regular UTC with, with the negative five offset, then that means that if it's midnight there, then it is a 7 PM our time,

right? So the UTC is basically the zero based approach that is a standard that you can look around the world and say, okay, we can figure out every other time based off this thing. So capital Z at the end, you're in UTC time. So if something happened here at 5 PM in the afternoon, we're going to add five hours to that. It's going to be 10 PM UTC. So 10 PM or 10, uh, that'd be 22, zero, zero Z, right?

So if I had to add Z on the end of my import file, even though I cheated, so I just thought it was something made by Nissan. You know, what's funny is I saw that stuff forever. It didn't, it didn't realize it had any kind of meaning. I didn't really know. It's one of those things like you don't care. You look at it and you're like, whatever. Yeah, exactly. That's something fancy.

The system will figure it out. But here's the crazy part. So the Z indicates it's in UTC. There are other ways to do that. You can also do plus 00. Or I don't think minus 00 is supposed to be formatted. I think, yeah, I think you can actually do that as well. So you could represent UTC as the time capital Z, or you could do it with plus zero zero or minus zero zero or plus zero zero zero. But, but essentially you can give it an offset of zero. So if you do the plus or minus, you have the ability to offset by a number of hours and minutes.

And this is important because most of us think in time zones of, hey, it's off by an hour. You're right. There are some places that are off by 15 minutes. There are some places that are off by 30 minutes. So the offsets aren't always, hey, if you move over from Georgia to Alabama, it's just an hour, but you might go somewhere around the world and it's off by a 15 second or a 15 minute increment. So it's important. And I think that there were some places in Asia that were off by 15 minute increments and I don't remember what they were.

Um, Oh, I got actually like a – if you pull up the – there's actually a Wikipedia for the list of time zones by country, and you can find some that are – like there's an island or group of islands out there near – well, I guess it's part of New Zealand or near New Zealand. Put New Zealand on the map. That is like 1245, like they're, they're, they have a 45, you know, kind of, instead of it being the hour. And then there's

others in here that are listed as like, um, 30 minutes or I haven't found the 50 minute one. Although I know there's one in there now that I say it, I can't, I was, Oh, here's one. Yeah. Uh, for man, how do you pronounce that? Man, one for Manmar, which would be like a 30 minute, like plus 630. Yeah, it's crazy. So here's the cool part is when you think about this, if you have the time and the offset set up, then you can always point to a point in time. So like I said, if we're looking at Georgia time and I want to represent that in UTC, then I'm going to say right now, what time is it? It's 1020 PM our time in Eastern Standard, right? So I know that that's five less than UTC time. So if we add five hours to that, then we could save it in UTC.

But if we want to represent it that, hey, this is the point in time when it happened in that time zone, we just say, hey, this happened at 2220 minus 05. And then you know that, hey, if you need to convert that to UTC time, you can, but you also have the point in time of where it originated, and that's very important. I want to mention it's really important to have that offset for a couple reasons. One is if we just did EST or EDT, there's also Australian Eastern and Australian Daytime. So that three-letter acronym is reused. And also I wanted to say that time zones do actually change. Like California was talking about ditching the daylight savings time change there for a while.

So if they didn't store those offsets with the UTC, you can imagine anything that was like scheduled in the future or whenever that change happens, it's suddenly like, well, in order to figure out what time UTC this happened, I need to know when this date was entered into the system. So it's really important to store that offset alongside it and just always go with UTC. Well, going along the lines of what you just said about them changing, because another thing too is like, you know, historically I would think of time zones as being specific to like where, you know, like where the sun would kind of, you know, rise and fall on a particular fall on a particular piece of the world, right? Right. But that's not necessarily always true. Sometimes those time zones are just set for political reasons, right?

They don't have anything to do with the actual time of day. And so there was a story that came out last year about North Korea. So to Joe's point about places changing time zones, they had historically been 30 minutes. North Korea was 30 minutes off of South Korea, even though they border one another. And they changed it so that they would be on the same hour. And then they recently reverted back. So they had that – they were on the same year for like three years, or the same hour for three years. And if you don't store that, you lose that information. Yeah.

So now they're 30 minutes – North Korea is 30 minutes different than South Korea, but yet it's not because it has anything to do with like where the sun, it's all, it's all political. Yeah. And so I think the last little bit to talk about on this, your offset can be in hours, hours, minutes,

minutes, or it can just be hours, hours. And then again, you can use the colon as a separator between the hours and the minutes, or you can just leave it off, but you have the plus or the minus, and then the zero based offset. So that's pretty interesting, right? Now the, the last part of this

date time ISO 86. Oh, one thing that I want to talk about here, and we'll mention some other stuff, but things get really crazy as you go on past. I wanted to hit on the basics. This one, if you have a combined date and time, the only real big deal is you put a capital T in between the date and the time. And that's what allows you to know that, Hey, this is sort of the separator. This, the date was on the left. The time was on the right, because if you remember, right, that T is kind of important because you can kind of truncate some of that stuff. I think on the date, right? Like you could just say you're 2019 and then, I don't know know put some other garbage on there and then t and then put your time stuff so go ahead i was going to mention too like one thing about time is it's kind of funny is you ever had a computer that

was just off on its time like for whatever is it just couldn't sync up or if you had a vm and you resumed it like a month later and it had like the wrong date or wrong time or something it just doesn't fix itself it's not any sort of logs or anything that happened in that time like you're doing that mental math to figure out what had really happened there it's it's all really hard to deal with too when you have a bunch of servers that you're trying to like match up logs and whatnot and the times are all jacked hey real quick too quick correction too like i was remembering that article wrong like they haven't changed yet but they were talking about changing reverting it back to where they would be 30 minutes.

So at the moment, north and south are the same. Because I know that everybody was hanging on the edge of their seats because that was important. And they were like, oh, my God, how long? That's crazy. Right. No, he's wrong. Screaming at their car. So here's one thing that's interesting, though.

Either basic or extended formats may be used when you're doing a date and a time, but you have to be consistent across both. So you can't take the colons and the dashes off one side and then leave them on the other and vice versa. If you choose not to use the extended format, you have to do it across the entire thing. Right. So that's basically it. Now the stuff that we're not going to talk about, but it's probably super useful to people that are thinking about, like we were talking about scheduling is hard. ISO 8601,

it supports that kind of stuff. So they also have durations, time intervals, repeating time intervals, and all kinds of other stuff. So, so they have things built into the standard to allow you to use that. And it's probably super useful if you're building a scheduling type app

because you can, Oh man, could you imagine? Right. I mean, so, so yeah, just be aware that it's there.

So we talked about all the ISO 8601 because I honestly believe if you're going to be creating apps that are going to be talking to other applications, you're creating APIs that are other applications need to use. Learn it. Know it. The standard, really? The standard. Know it. Oh, no. Because like I said, languages don't necessarily support them natively, which kind of stinks in my opinion.

I want to think about this as little as possible. Man, it's so frustrating. This episode is sponsored by Clubhouse. Clubhouse is the first project management platform for software development that brings everyone together so teams can focus on what matters, creating products their customers love. While designed to be developer-first, the UI is simple and intuitive enough for all teams to enjoy using. Do you hear that? Developer first. That's for us. And when I say things like that, I mean things like they've got Git tips in there, so you can easily create branches or they'll actually give you the commands that you can paste into your command line. That's because this tool has been designed for our perspective first.

Yeah. And along those lines, they just introduced a Bitbucket cloud integration. So now you can track the status of your pull request by automatically associating a branch with a story. You can associate pull requests with stories to give colleagues visibility to when a PR is opened and after, and you can update the story states automatically with workflow triggers and event handlers. So yeah, there's great developer integration. When you log in, you'll immediately see your work queue, active tasks, and upcoming due dates.

So you're going to know if you're late on something and you'll see an activity feed of what your colleagues are working on. And with a simple API, remember, developer first, and a robust set of integrations, Clubhouse also seamlessly integrates with the tools you already use every day, like Slack or GitHub, for example. It's getting out of your way so you can focus on delivering quality software on time. Go ahead and sign up for two free months of Clubhouse by visiting clubhouse.io slash codingblocks.

Again, that's clubhouse.io slash codingblocks to get your two free months and see why companies like Elastic, Full Story, LaunchDarkly, these all love Clubhouse. it's that time of the show that we ask that if you haven't already left us a review, we would forever be in your debt and be really appreciative. If you would leave us a review, you can find some helpful links at www.codingblocks.net slash review. And, uh, as you may have heard me say once or twice,

you know, share us with a friend, tell a friend about the show too. We would appreciate that too. You know, spread the word. And so with that, we will head to my favorite portion of the show. Survey says, all right. So, uh, all right. So, all right. Episode, a couple episodes back, episode 98, we asked, how much time do you spend coding

outside of work? And your choices were, nada. I don't write code for free. Or, until I go to bed. Or, I take the weekends off. Otherwise, I'm writing code. And last, like a sine wave,

I go through phases. Sometimes more, sometimes less. Alright, so... My name is Joe. Okay. I think... Oh, definitely like a sine wave. Definitely.

Okay, like a sine wave? Definitely. And the percentage is 42%. Wow. 42%. He's confident with his choice here. It is. Sometimes I'm just right. There's not a song for this one.

Oh my god, that reminds me. Sometimes I'm just right. There's not a song for this one. Oh, my God. That reminds me. Coding for the very first time. Oh, Jesus. All right. Oh, boy. So, man, that was the one I was going to pick. I definitely wasn't going to shoot that high.

Let's see. I'm going to say I take the weekend off. Otherwise, I'm coding. Or otherwise, I'm writing code. And let's go with 33%. Okay. So our choices are like a sine wave at 42%. Like a sine.

Or I take the weekend off at 33%. Yep. And Alan, you are definitely the loser oh man you overshot i did big time really yes wait not even close was that the answer though that was the last answer oh that's terrible yeah by a lot it was it was far and away like a side wave oh really okay cool yeah and it was far and away like a wave oh really okay cool yeah and it was like 73 percent of the vote wow far and away the winner oh that's awesome yeah i was really surprised by that but it made me feel good because i i definitely am i'm a sine wave yeah yeah i'm definitely like there are times where it's like you know what no i i've i'm gonna go mountain biking or i'm gonna play

guitar or something else. Right. And then there'll be like the winter months, especially are when like a kind of hunker down and we'll do more like kind of learning. I consider it learning, whether it's like reading books or coding or whatever, like those kind of things. But when it's nice weather. You know, it's funny for me. Mine's sort of the inverse. I think I get cabin fever during the

winter and so i want to go outside and do things and i'll find myself just because it's so hot outside in the summer where we live that especially in the evenings i'll just i'll be sitting there doing that stuff until midnight 1 a.m whatever so but yeah that's awesome we are i think you're probably the same right well joe i think you always write code i'm. I think you're probably the same, right? Well, Joe, I think you always write code. I'm not sure that you're assigned. Well, it's summer year long too. So there's no seasons down here.

Unfortunately, it's in the eighties today. It's too hot, man. Like 85. Dude, that is kind of crazy for we're in February. Yeah.

Yeah. Yeah. Eighties. Get out of here. You know, you know, though, Alan, I got to ask you because you just graced us in song. Yeah, it was good, right? Yeah.

Yeah. You just had a little hurt over there. Yeah, I just thought it was going to be 42% for sure. I mean, you still won even by Price is Right rules, right? You didn't go over. So you won. You won. You picked the right answer and you didn't overestimate it.

So good job. But, you know, Alan, do you ever – okay, so a little behind the scenes here, right? So, you know, when I'm putting the show notes together to publish the episode, right? And I try to find some little one's cool things to put as the intro, right? And usually, too, I'll use that same kind of blurb when I'm socialing out, hey, everybody, latest episode's out, whatnot, right? I'll use that same content there for that part too. Cause, because in my mind, sometimes it's funny.

I, you know, you might, some, some are probably funnier than others, but I'm kind of curious, like, do you pay attention? I feel like I need to go look up what was the, do you pay attention to them? Like, cause I mean, you get, you get, you should get notifications about it from the various platforms. Like, Oh, Hey, you're including some sweet songs. Yeah. Yeah.

There you go. That's right. That's right. I remember. I was, I wasn't sure. Like if it, if it like, uh, you know, if it caught your eye, if you were like, wait, I did. No, I didn't see that.

But you know what's amazing is I feel like I should go Denzel now and be like, you know, Lionel Richie ain't got all me. Okay, King Kong, calm down. That's right. Gave it right here. Oh, man. All right. So today's survey is how many conferences do you go to per year?

And your choices are, I usually average one to three conferences a year, or somewhere in the range of four to six, or more than six, but nothing crazy. Or I go to all of them that I can afford or my company can afford. Or I travel all over speaking at conferences, so I go to too many. Or lastly, zero. I don't like them. They're too expensive. They take too long.

They're too far away or some other similar reason. How many would you go to? What would be your ideal number there? Oh, man. Now I feel like we're going to taint it, though. Well, no, this is ideal. Not like how many do you actually make it to. Yeah. I'm going, only two.

See, I was going to say one a quarter. So I was going to say like four. But I think that part of that is, are you traveling far for them? Like if they're local, and at least we're able to go to several locally. Because we live in a pretty decent tech area. I don't know. Actually, I'd probably say three. Mine kind of borders on topics that would be interesting, right? Like frameworks that are out, data things, big data things coming, and maybe

machine learning type stuff. Mine would be very topical. That's important too. That's an important call out too, is that the four that I'm thinking of, like not the same theme. I don't want to go to a bunch of JavaScript things. I don't want to go to a bunch of C sharp things. Like I want to hit one of each, right?

So that I'm constantly, you know, keeping my, my full stack, not a myth thing going. Right. Yeah. This year I'm on schedule to do so far one a month. Wow. But a lot of it's local, so it hasn't been too bad. I've been to two already. I have two coming up in March. Wait, wait, wait. Are we talking

conferences or meetups? Conferences. You're going to one a month? That's been my schedule so far. That's going to one a month? That's been my schedule so far. That's going to fade off in February. I think what I was looking at was basically doing six or seven this year. I think that's my limit.

I only go to Saturday conferences basically, which is also a bummer because it definitely feels like work and I'm tired, especially if I'm traveling. The three-day conferences, I don't love them. It's a lot. It's overwhelming.

Especially if you travel, you're staying in a hotel like three days. I like the Saturday ones. I feel like you get a lot out of them. Yeah, I definitely wasn't thinking. When I said the four, I wasn't thinking like four, three days either. Right. So, yeah. I was kind of thinking like you can maybe squeeze in one or two of those,

but definitely not. Yeah, because something like Ignite, that's almost a week-long event. That's a lot. That's a lot. But, yeah, I go to pretty close to one meetup a month. Plus, I would say. Well, one meetup or one conference? Well, one meetup a month and one conference every two months.

Oh. That's probably my average. It's too much, though. It's too much though it's too much it is a lot but it is a nice way to stay involved it's almost like listening to a podcast except you interact with people too right so yeah yeah you throw the podcast in there and then like a couple uh open source projects and uh that's pretty much uh all my all my time that and pokemon yeah that and pokemon definitely, definitely, for sure. Priorities.

Camper's out now. That's right. Priorities. This episode is sponsored by Datadog, a monitoring platform for cloud scale, infrastructure, and applications. Datadog provides dashboarding, alerting, application performance monitoring, and log management in one tightly integrated platform, so you can get end-to-end visibility quickly. Visualize key metrics, set alerts to identify anomalies, and collaborate with your team to troubleshoot and fix issues fast. Try it yourself today by starting a free 14-day trial and also receive a free Datadog t-shirt when you create your first dashboard. Yep. So go to www.datadog.com slash coding blocks to see how Datadog can provide real-time visibility into your application. So again, that was www.datadog.com slash coding blocks to sign up today.

All right. So here comes the fun part. And this is stuff that, man, I actually hate to admit it, but I'm human. And I just learned about this. Wait, you hate to admit you're human? I hate to admit that I learned something that seems this basic after so many years of using something. So, man, SQL Server. Outlaw was talking about defaults. And, man, I guarantee you all three of was talking about defaults and man, I guarantee you all three of us have used get date a billion times in our career.

Still do. Right. Because it's, it's the one that makes the most sense when you look at it, you're like, Oh, good date. Sweet.

Yeah, that makes sense. Perfect. That's my guilty developer confession. Still use it. Oh man. So I'm going to break down some things for you that are going to be somewhat interesting, really, really propeller hat type stuff.

But it's nice to know how these things work behind the scenes. So in SQL Server, go look up your RDBMS of choice and figure out how things are working there because you probably want to be aware of them after this. But in SQL Server specifically, datetime values are stored as two integers for a total of eight bytes. They are based on the Gregorian calendar, which I have a link in the show notes if you are interested in what the Gregorian calendar is, but just be aware that you have a date and a time portion. All right. The first integer is the date and this can represent, and this is why I said it can be less than 1900, January 1st, 1753 through December 31st, 9999. Okay, cool. We don't need dates before 1753 or after 9999. We're good, right? Here's the interesting thing.

The value of zero in that left bite part or the left part of that bite is one, one 1900 positive numbers are the additional days after that. So if the value, if you have a value of two, that is one, three, 1900. The value of two is add two days to one, one 1900, right? Negative numbers are the days before that.

So negative two would be 1230, 1899. And that is basically how you derive your dates. And that's why you have the weird range you do from Januaryuary 1st through december 31st 99 99 so okay it's kind of interesting the second integer value is the time now this is where things get completely whack all right so this represents because they weren't whack before right now we're right we're fine no this is this is where things will really bother you when you start thinking about this and start realizing what you didn't know. So, 0, 0, 0, 0, 0, hours, minutes,

seconds through 23, 59, 59.997. That's what this integer can represent. So zero all the way through 23 hours, 59 minutes, 59 seconds, and 997 thousandths of a second. So you didn't see a nine nine nine there. Why? That's absolutely crazy. It's because this integer for the time represents the number of three thousandths of a second after midnight. So 333 as the integer on the right would roughly be one second after midnight because it's in 0.003 increments. Wow. So to make things worse because they're not bad enough yet because it's incrementing in three thousandths of a second, the values are rounded to the nearest zero zero zero zero zero three or zero zero seven.

That was the craziest part of all of this to me. Like where? Why? How did you land on that? Dude, and you know, the funny part is I can't tell you how many times over the years that I'm like, hey, I want to put in the end of the day, but I don't want it to be 24, 0, 0, 0. I want it to be 23, 59, 59.999. And I've gone back and looked at the date and I'll see 997.

And I'm like, maybe I typed it in wrong. I can't tell you how many times I've thought that in my career only to realize later that no, it rounded it down to zero zero seven or nine nine seven in this case. Crazy. So be aware of that. Your precision is probably not what you thought it was, right? And if you need to store things down to the nanosecond, a date time specific type will not get you the accuracy you need. Wow. And I've got some code. I've got some code here that I wrote up to play with this stuff to show what's going on. I might even make a video on it. Cause it's really interesting to see how this stuff works. Like I'm actually, and I got this off a website. I've got a link in the, in the docs. It's, it was actually from a red gate post that was really, really well done.

But anyways, yeah, I've got this code might show up, but it'll definitely be up on the site. You can go copy and paste it and run in SQL server and you'll see what's happening. It's absolutely crazy. If you want to see this code, then you should tweet it. Alan told him that he can't make a video about it. Uh,

right. Psychology. There we go. Well, it reminds me of, uh, like one of my, I don't tweet often,

but when I do, there's, there was like this one joke that like I put out tweet often, but when I do, there was this one joke that I put out there that I was like, oh, this one I actually kind of find funny where it was like, oh, SQL Server, I'll never understand you. And it was like, this is a timestamp, not a date. But yet you would call getDate and it would return back the full timestamp. And I'm like, this is also a timestamp. But yes, I was walking through all the... Not all of them, but some of the various functions and I'm like, this is also a timestamp. But like, yes, I was like walking through all the, you know, not all of them, but some of the various functions and it was like, these are all weird. Yeah, man, I'm telling you right now, this was eyeopening to me. Like when

I actually had to deep dive all this stuff and, and I deep dived it before this episode because I've run into problems that were, that were causing me headaches. Right. And this is why I went to the ends of the earth to figure out what was going on. So, so that's all fine and dandy, right? Like we've got this date thing that's got this weird range in it. And we've got this time that sort of gets it all the way down to the millisecond sort of, or the nanosecond, but there's a piece missing. And it's something that you probably don't consider. If you're just writing apps and you don't think about it, there's no time zone, there's no offset. And that's a big deal. If you are storing data that needs to be represented in different time zones around the world, that's a problem. So date time is not going to give you what you need. So let's see.

Oh, here's another thing, a little note that I have. With you, and I might have this somewhere further in the notes, but there's a difference between talking about a time zone and an offset, and we've briefly mentioned that before. You can always get the offset from a time zone, but you can never get the time zone from an offset, right? Because as we mentioned, there's multiple time zones for this particular offset that we're in, which is negative zero zero or negative zero five here, right? There's three or four different time zones that you have, but you can't reverse engineer the

other way around. So just be aware of that. If you're going to store, if you're going to pick one of the two, you probably want the offset because that's probably the most useful in most cases. You might have some cases where you want the, the time zone as well, but you can't reverse your way back to the time zone. And so if the So if the time zone is important to you, you need to store that separately somehow. So, for example, if you were to say UTC plus 5, plus 05 colon 00. Right, right. You could be referring to some islands that are part of France. I'm not sure how you would pronounce it, but the Kyrgyzstan Islands, maybe?

I probably really butchered that one. I'm going to stop trying to pronounce these various places and just say, like, France. Or part of Russia. Part of Antarctica. Or part of Russia, part of Antarctica, or part of Australia, or Kazakhstan. Kazakhstan. Oh, that's what I meant to say. Yeah.

I said it that way. You heard what you wanted to hear. Kazakhstan, I think, is the actual way to say it. Yeah, that's what I said. Specifically Western Kazakhstan. All right. Or, I mean, there's like other places too. Like Pakistan is in there.

Maldives. So to your point, yeah, like if you only gave that offset of UTC plus 05 colon 00. Okay. You can't get back to it. No. And again, know your application, right? Like, does it matter? If it doesn't, then maybe you don't need it,

but know what you're actually going to need. And if you ever have any inclination that you're going to need any of it, store it. Yeah, that's really the problem though, right? It's like, you might not know you need it until, you're not going to know you need it until you know that you need it. And that might be too late to find out that you need it. Yeah, it's possible.

It's definitely possible, but you can't go wrong with at least storing the offset, right? Get that more than likely if nothing else, get that. So here's some of the problems with date time. Just, just so we get these out of the way, you have no way of truly knowing what time offset or date time it originated from. You saved it. It's done. Did it come from your application and come from the server? You don't know. You hope, you know, but you have no guarantee, right? And then you lose position. You lose that precision. Like I said, it does rounding. If you weren't aware of that, that's a big deal.

You may not care because your use of it may not require that you have it down to the nanosecond, but be aware that you are losing rounding precision there. Common methods that you use, that we use, are get date. It's probably the most famous one. And then here's another one that is helpful for you. If you are going to be using date time fields for storage, if you use get UTC date, you're guaranteed that you'll get your date time in the zero offset, which is the coordinated universal time. So if nothing else that you take away from this right now is consider using get UTC date instead of get date. It still has the same precision problems that a date time will have,

but at least you have zero offset, assuming that your system set up in the proper time zone in the first place. Right? So, I mean, you can totally shoot yourself in the foot with date times just by not setting your, your particular system up in the right time zone.

Well, speaking of getting shot, if you're the first person at your organization to swap over to get UTC date, you created one table and all your other tables are done in some other time zone and you're the first one going UTC, get ready to get shot because that's going to be a pain. I don't really know what it takes to migrate a big system over. Ultimately, the sooner you do it, the better because otherwise you're just going to be a pain. I don't really know what it takes to migrate a big system over, but ultimately the sooner you do it, the better because otherwise you're just going to keep building stuff. But that's going to be a major hassle for pretty much everybody I would think. But you definitely don't want to just go off and start creating your next set of

tables in UTC if everything else is done in plain old whatever. In local. Yeah, I mean that's the most important thing is you really have to be aware of what you're doing with date times. Like I said, the biggest problem is not knowing what you're not facing. And that's the part that comes back to bite you eventually. So if you want more precision, there is this other thing in SQL Server because, you know, there wasn't a better name around date time too.

If you need precision down to the God, I wasn't a better name around date time too. If, if you need precision down to the, God, I don't even know. It's a, let's see how many decimal places did I say it? It's one, two, three, four, five, six, seven. So if you need precision to seven fractions of a second decimal place wise, then you can use date time too. Now an added benefit of date time too, is you can actually represent dates from 0101, 01. So January 1st of the year one, all the way through December 31st, 9999, all the way to 23 hours, 59 minutes, 59 seconds, and seven nines of precision. No rounding. It actually saves it in that precision.

So super important that you're aware if you need that extra precision and you need that extra date range available, go with the date time too. Of course, it is a little bit more storage. I forget. I think I don't remember. Of course, it is a little bit more storage. I forget. I think, I don't remember. I might have it here somewhere. Okay, here we go.

It's actually kind of interesting. So it can be smaller than a date time. So storage size is six to eight bytes. So it can grow and shrink. So it can be smaller than a date time, but has precision to the nanosecond, which is really good. For the date time to data type, the first byte stores the precision. And the last three, wait, wait, server use the first byte to store the time precision and the last three bytes to store the date and everything in between to store the time, which can vary in length depending on the specified precision. And that's where you can get a size of six to eight bytes. It depends on how accurate your time storage is.

So. Pretty interesting stuff. Let's see. Oh, here's another thing that's really cool. And this will save you size too. In get date or in a date time field, you have no ability to say that you just want to store down to the second, right? If you're going to store a date time value, you're going to get second dot zero, zero, zero for your millisecond stuff, right? Or the fractions of the second. In DateTime 2, you can actually tell it, hey, I don't want to store any precision after the second.

So you can declare your variable, like if you say my DateTime 2 as a DateTime 2 and then open parentheses zero, that tells it kill off all the fractional seconds. And so you can actually trim down your storage. So that's kind of a nice, you know, by-product of using daytime too. And I want to mention too, like we're focusing heavily on SQL server because that's the one we work the most with,

most with, but I'm sure if you Google Postgres, which I don't know, we're going to call that like SQL server junior now, I don't know if you want to Google my SQL or whatever the database system using SQL or not. Yeah. Like I said, we're giving some information about the stuff that we use a lot. My guess is every system out there is going to have some sort of weird nuances on them, right?

Just get familiar with them. Know that these snuck up on us and we've been using these things for a long time. So yeah, your storage, your memory stuff, like I said, depending on how much precision you're using, that's really good. Nice benefit of this. Now here's the thing about date time to get rid of your good old used get date function. you're going to use sys date time. Sys date time is the replacement for using a date time to value. If you want the stuff with UTC and you wanted a date time to precision, you're going to use this UTC date time. So throw get date out the window, throw get UTC data out the window and use these

sys date functions. Now, another thing that we notice here is we're talking about precision down to the nanoseconds for times. What we still don't have is we still don't have the offset with the date, right? So date time two still does not solve that problem. So what if you need... Date time three? Say what? Yeah, date time three. There we go. You would think, right?

I mean... Hey, what's better than seven-minute abs? Six-minute abs. Oh, man. So here's the thing. If you actually need to know where it happened, if you need an offset, right, like where around the world at what point in time did this truly happen, you're going to basically use the datetime offset type in SQL Server. So the storage is 8 to 10 bytes. The additional two bytes are for the date time offset. Now what date time

offset gives you, it's essentially a date time two plus an offset. That's really all it is. It's the same storage with the two bytes for the offset, not time zone, not time zone, the offset. So plus or minus, and then, you know, hours and minutes. So maybe crucial if you need to know when something happened at a given point in time at that local time, wherever it happened in the world, right? Super, super duper important to know. So there's a new method. If you're going to use the offset one, which is sys date time offset, that's the one that you're going to use the offset one, which is sysdatetimeoffset. That's the one that you're going to call that will give you the current time with the offset information that you could store in your datetimeoffset field. My recommendation is, if it's a question, use that one,

right? Take the hit on the extra two bytes of storage and just use it. It's not going to kill you to store the extra bit of information. If you ever need it, you can use it. But if you don't have it, you can't use it, right? So if you're in SQL Server world, take a look at datetime offset, get familiar with that method and you should be good. Now, I do want to point out, we've talked about the offsets. We've talked about all the precision and everything. What we still don't have is we still don't have the time zone, right?

And I mentioned, you can go to the, you can go from a time zone to an offset, but not the other way around. So if you need time zone information, you're going to have to create a separate field and store it in it. Period. That's basically it, right? Like there's no, there's no silver bullet, at least not in SQL server that I'm aware of to where you can store the date time plus the offset plus the time zone. It doesn't exist. I don't believe. Joe, you have a look.

Yeah. So I got distracted. I was trying to figure out who runs have a look. Yeah, sorry. I got distracted. I was trying to figure out who runs NTP servers. Is that like the government? I ended up down a rabbit hole. That's hilarious. Yeah, sorry. So I missed a bunch of what you're saying.

So the important thing is there is a standard list of these time zones, and it called the Olson time zone and it's a full string representation. So it's not like, you know, typically it's not just going to be a, you, it's going to be something like, you know, us East or something like that.

But I have a link to the Wikipedia article, highly recommend if you're interested at all, go check that thing out. So like, for instance, you'll have Africa slash Dakar, right? That's the full time zone, America slash Glace Bay. So it's definitely a full name thing, and you'll have to set aside additional storage for that.

Whether you need to or not, up to you. Don't know. And this is what I'm talking about, where i was like america los angeles like the the tz database name or new york like this is official designation like this isn't just picking a random city like right well defined it's official yes so so two two quick points one to joe's comment about the the time like who maintains the NTP servers. So in terms of network time protocol, fine. Maybe I'm not sure who that one is, but if I recall the original origin of it, I believe it was the power companies, if I recall, that controlled it because they would sync clocks

by the cycles through the power, if I remember correctly. Now, I could have that wrong, but I'm pretty sure I'm somewhere in the ballpark of that right information. And I tried to find it while you were talking about other stuff, because I thought that'd be an interesting segue or a neat little tidbit, but I couldn't find something specific. But I'm pretty sure I remember that that's how it was. Like, and so if they needed to like adjust the clocks for like the leap seconds or something like that, the power company could adjust the frequency enough. Like they could,

they could make just such a subtle change that it would, you know, clocks that were synchronized over power, then they would, they would get that. That's crazy. Wow. Another thing that,

that I wanted to point out too, is that like, you know, some of this, as we're saying, like I wanted to point out too, is that like, you know, some of this, as we're saying, like people want me to think like, ah, who cares?

Right. Like I'm going to do, I'm going to just, you know, whatever, you know, look, man,

I'm using Apache and whatever Apache, uh, you know, puts out their output as the, a fine, I'm using log for net, like I'm using well-known, well-trusted libraries and whatnot.

Fine. And maybe, but here's the problem though. So then you decide, hey, you know what? I want to aggregate all my logs into one place, right? We're a Splunk shop. We want to bring all our logs into one place. Or we're an Elastic shop. We want to bring all of our logs into Elastic.

We're a Datadog place. We want to bring them all into Datadog, right? Like whatever your, you know, whatever your aggregation of choice might be, right? So let's say you do that. Apache will include an offset for you, right? So you will have that in your standard log. Now we're talking about kind of defaults here, right? You'll have that in there. Log for net won't. It'll just give you the time to the millisecond. At local. Yeah, well, yeah, at whatever the local.

Local on the system, not where it is. Local on what the system set up is. Whatever that system is configured as. So now you want to aggregate those things together and be like, hey, I see that there was this request made and it went through the application pipeline. Oh, wait, I just lost, because this server, this particular server is in US East,

but this other server that it originally, that a request got bounced to was in US West, or you know what I'm saying? I do. Now you're at the creek, right? Because all of your times are going to be. That really upsets me. It's going to make it look like the same request happened hours apart.

When they did. In the same place. Right. The same locale. But they didn't. So you want to know what bugs me about that is one i didn't know that about log for net and two it's an apache project why if apache does it did they not do this in the apache project you probably i'm sure there's some plug-in or

configuration you can make now but it's funny i never thought about it i've never yeah it does it in local time man that hurts all right. All right. What else you got? That's what I'm saying. Well, those were my two things. One, sinking power over – sinking time over the power line because I remember – and the only reason why I even know about that was because we've talked about security now before. And Steve Gibson talked about that sometime last year. I remember there was an episode where he was talking about that sinking across.

And I just thought it was kind of interesting thing that kind of related. And when Joe asked like, Hey, who maintains this thing? I was like, I might kind of know something that relates to that answer, but I don't know if it's the answer. That's crazy.

It's really complicated. I kind of thought there'd be like one, like ISO, you know, whatever backer, but it seems like a bunch of different people run NTP service and you can run your own too. That kind of set the time. So it was kind of interesting. That's really important for like, um backer, but it seems like a bunch of different people run NTP servers, and you can run your own too to kind of set the time. So it's kind of interesting.

That's really important for like apparently GPS. Time is really important because of how it kind of translates where you are. So if you're dealing with multiple satellites and they're off by seconds or time zones, then you're going to get some pretty off answers. Time syncing is very important, apparently. You mentioned we'll have a link to those names there. We actually are going to have a ton of links in this article. And one thing I wanted to call out now, just while I was thinking about it,

is Complete Developer Podcast actually did a three-episode series on the history of time and just a bunch of stuff about time. And they cover a lot of different stuff. They actually talk about the evolution of time and just a bunch of stuff about time. They cover a lot of different stuff. They actually talk about the evolution of time itself, like agriculturally up to computer-y stuff that we're talking about. It was a great series to listen to. We'll have links to that, too.

Cool. All right. Now it's that time of the show that... Wow, I never say this right. Now it's my favorite part of the show. It's the tip of the week. It's funny. You had to think about it. What did I say? The times are all

jacked up in my head now. Does anyone remember what my favorite part of the show was? I don't think you ever came up with one. I did. Don't say it. Wait. Alright. So anyway, my tip of the week. But I did say it. Oh, I didn't say it. Wait. All right. So anyway, my tip of the week. But I did say it.

Oh, I didn't hear it. Dang it. Oh, well. Secret's out. They're going back. It's tip of the week. It's the end of the show. It's the end of the show.

That's how I'm going to do it from now on. When we get to the end, I'll be like, now it's time for Joe's favorite favorite part of the show it's the end of the show that wasn't my favorite though it was at the tip of the week who knows uh the dankest memes right oh wait yeah so i was trying to beat outlaw that's right he still has it he's still you're not dank are you no i am are you i found it did you uh i did he? I don't remember. I got witnesses. You're in there? Whatever. We're playing some inside baseball right now. You should join Slack if you haven't already and we will involve you

in this weird mystery. Totally. Found ourselves entangled in the drama. That's so anticlimactic though. Your tip of the week, Joe. What do you got? My tip of the week joe what you got my tip of the week is that uh critterl rutted on uh on slack mentioned to me that you can get edge to read out epubs to you which is really nice because there's definitely a lot of tech material that i would

love to hear audio of and i don't want to i don't want to read because it makes me fall asleep really fast. And so I've got a link here on how to do that. But in the meantime, I kind of thought like, you know what, let me just like Google EPUB audio Chrome. And I saw that there's actually a couple apps that are specifically designed for reading PDFs or EPUBs or whatever, just out loud. So you just kind of give them the file,

you open it up in Chrome, whatever you have as an extension. And there's's ones for edge too but i just tend to use chrome so that's kind of my preference so i downloaded one of those i haven't given a shot yet but i'll let you know how it goes that's really cool yeah it'd be great for meeting a pragmatic programmer because there's not a lot of code examples oh pretty nice. All right then. So my tip of the week is actually nothing super technical this time, but I think in episode 100, we talked about, you know, developer machines and laptops and he was like, Hey man, I found, you know, there's a laptop you might be interested in. But the tip that he wanted to share is one that is so true. If you're browsing around on a site and you're shopping for laptops, computers, service, whatever, if there's a chat with somebody thing, do it because they will almost always give you a discount and it's usually 10 to 15 to 20%.

So if you find yourself super interested in whatever you're trying to purchase and there's a chat live with somebody now do it. It might take a few minutes of your life, but chances are you'll get a halfway decent savings. So excellent tip. And it's one that I do all the time. Don't even think about it anymore. Right? Like if I'm about to hit the purchase button, I'm like, Hey,

what can you hook me up with here? And always works. How much does the discount have to be worth it to interact with another human being? Yeah. Can I pay extra to not, isn't that what the internet's all about? But you know what?

That's the thing though. Like usually if I'm shopping for something like that, to not isn't that what the internet's all about but you know what that's the thing though like usually if i'm shopping for something like that it's not like it's the only thing i'm doing right like i've got other things going on i'll be on another tab so it's like man it's not gonna hurt i'll let the person try and sell me on it and then be like hey are you gonna make it worth my while and then well we can see what kind of discount we offer you all right cool well that's not good enough i'll be back later right like but you can almost can see what kind of discount we offer you. All right, cool. Well, that's not good enough. I'll be back later.

But you can almost always get some sort of discount. So it's worth it. I mean, you're not really interacting with anybody in real life, right? Like it could be machine learning algorithm out there. It could be an AI that you're chatting with. It's possible. It is nowadays. All right. So my tip of the week is Python has a cool feature where you can use a virtual environment for your development needs. So I'll include a link to it, but you can install a, well, install sounds like a maybe overstatement, but yeah, you can configure a virtual environment. And in that

virtual environment, it'll have all of the binaries and all of the versions of everything that you're using in it. So once you create the virtual environment, you can activate it. And now you can upgrade the version of Python or pip that you're using, for example, within that virtual environment, but the actual system that you're working in isn't affected. This sounds like a Docker container. Well, okay. So think along those lines, except this is all like directory based, right?

So you could have, you could be doing Python development for say, you know, eight different projects, right? And eight, those eight different projects, they might have different dependencies, right? And those eight different projects, they might have different dependencies, right, for different packages or different versions of Python or whatever, right? And this is a way that you can source an environment for each one of those as you're working on it. So you can activate or deactivate a virtual environment and then have different dependencies baked into it without actually affecting the root operating system version of Python that you're using. That's really cool. So I'll have a link to that. So if you're doing any kind of Python development and you're not already using that, you know, it's a neat,

it's a neat module out there that you should be aware of. All right. So with that, we hope you have enjoyed this brief introduction to dates and dating. Be sure to subscribe to us on iTunes, Stitcher, and more using your favorite podcast app. And as I mentioned earlier, we would greatly appreciate it if you would leave us a review. You can find some helpful links at www.codingblocks.net slash review. Yep, and while you're up there, go ahead and check out our show notes, examples, discussions, and more. And fend your rants, questions,

and feedback. Did I say fend? I don't know what you said. Oh boy. Yeah, I don't know. To the Slack channel, codingblocks.slack.com and make sure to follow us on Twitter at Coding Blocks. I think we're really close to like a milestone with Twitter follower to the slack channel codingbox.slack.com and make sure to follow us on twitter at codingblocks I think we're really close to like a milestone

with twitter follower count I don't actually remember what that is though so you should go there and follow us if you aren't already and sometimes we tweet funny things

and of course if you go to the website you'll find social links to the top of the page where we have all sorts of other stuff yeah I think if we cross that milestone

Joe was saying something about like he was going to dye his beard rainbow color or something something like that yeah i think i heard that yeah yeah rainbow beard for my uh for my cousin's wedding awesome let's not forget this is the man that still owes us a tattoo so clearly he will see this thing through yes yes there's no doubt yeah