As a Real Programmer(tm) I have developed such a deep fear of anything time and date related that I would fully endorse dispatching an API call to the tz_database instead of attempting any fucking part of this.
Kids, it's fine to meme about silly stuff... but date and time is deadly serious, regardless of how careful you think you're being you are wrong.
Do you know how many timezones there are in Indiana? No? Look it up and scream in horror.
What if I told you that weekend days are locale dependent?!
Time and date is the black hole where optimistic programmers go to die. Nothing is simply with localisation and if you think it is, you mustn’t have worked enough with it.
Source: Run a system that schedules millions of interactions across the world and deeply depend on this. The amount of code to manage and/or call out to external services to give us information about time zones, summer time, locale specific settings, day names, calendar systems, week numbers etc etc.
Here's a fun thought experiment: What gregorian year and date will the spacian date value of zero correlate to? Trick question.
The atomic clock on the moon and every other celestial body colonized will simply start at zero, and thanks to relativity it will not actually be the same rate of time passing as on earth.
IMO every datetime should be in utc, and variables for datetimes should either be suffixed "Utc" or have a type indicating their time zone (DateTimeOffset or UtcDateTime etc). Conversion to local time happens at the last possible second (e.g. in the view model or an outbound http request parameter). Of course that doesn't solve the problem of interoperating with other morons programmers who don't follow these rules, but it keeps things a lot neater locally.
Scheduling based on regional time conventions (holidays, weekends, etc) is just not great though.
Throwing UTC everywhere doesn't solve comparisons around leap seconds. I'm sure they're other issues with this method, but this is kinda the point of "just use a library". Then it's someone else's problem.
Honestly the first one is the only one that works when people define the first day of the week differently. On the other hand, it does make you wonder. If Sunday is the first day of the week (as it is in many places) then how is it also part of the weekend?
But if you're worried about locale, you can't assume people use the string "Saturday" to describe Saturday either. That solution only works in English.
I'm refering to end in a temporal sense because we are talking about a time context here. There is a clear direction so going backwards brings you to the begin.
I'm English, not American but I see it as Saturday and Sunday are the two ends of the week. Like how a string has two ends. The weekend is both the start and the finishing end of the week.
So, when someone asks if you are free the next two weekends, you assume they're talking about the next Saturday (tail weekend) and the next Sunday (front weekend)?
yeah I like having an array of days that are weekend days then testing if the day is in the array. can change what days are considered weekend if we go to a three day weekend and it reads really well. I hate massive if statements
I'd make it a named function for clarity and testability and proceed to give zero shits how it is implemented. I would unironically write this code if it worked, but I wouldn't inline it to reduce the cognitive load of reading it.
Depending on whether this code is in a hotpath (and considering how "elementary" it is, I figure that's a possibility), this could very well be a significant speed improvement.
Though I'd say that only excuses it if it's truly an elementary function (and not one line as part of a larger function), as otherwise it's unreadable garbage. But on its own it:
has a clear purpose
(presumably) isn't reimplementing functionality
is easily tested
can be modified with no side effects (besides breaking your calendar, but that's beside the point)
It's one line as part of a larger function. Also, it doesn't actually say weekend, it just executes some other functionality if !(day % 6). I made it more readable so that everyone here could understand what it does