I have worked with these before but have forgotten what I’ve learned, probably because I didn’t learn it correctly to begin with.
The Date object in JS may be replaced, or rather, joined by, an object called Temporal which is meant to fix a lot of issues that Date supposedly has. Date can’t be replaced or changed much though, since so much of the web uses it.
I also know that there are many libraries that allow for date manipulation
- moment.js - feature rich, great docs, kinda big, no longer actively developed
- day.js - smaller than moment.js, with faster load times - needs plugins for things like timezones
- date-fns - modular, great typescript support
- luxon - smaller community, less mature
Basic Native Date Manipulation
const theDate = new Date()
// By default seems to be displaying like this
// 2024-12-04T21:41:25.574Z
// But in the browser it sort of displays it differently, like this:
// Wed Dec 04 2024 16:42:08 GMT-0500 (Eastern Standard Time)
// custom date object
// In military time
// year, month, day, hour, minute, second, ms
// ms are optional
const customDate = new Date(2024, 0, 1, 1, 1, 1, 1)
console.log(customDate)
// We can also pass in a string representation
// "<year>-<day>-<month>T<hours>:<minutes>:<ms>Z"
// Z makes it a UTC time
// const date = new Date("2024-01-02T12:00:00Z")
// Also possible to pass in a given amount of milliseconds sinc epoch, epoch timestamp
// 1.7 trillion milliseconds is about 2023
// 1,700,000,000,000
const date = new Date(1700000000000)
console.log(date)
// get year
const year = date.getFullYear()
//
const month = date.getMonth()
const dayOfWeek = date.getDay() // this is day of the week
const day = date.getDate() // get the date
const hour = date.getHours() // gets hours
const minutes = date.getMinutes()
const seconds = date.getSeconds()
const ms = date.getMilliseconds()
console.log(new Date().getMilliseconds())
// create date with a simpler string
// note that here, the months AREN'T 0 indexes since it's human readable
const newYears = new Date('2024-12-31')
const newYear = new Date('2025-1-31')
if (newYears < newYear){
console.log("happy new year bruh")
}
// we can compare dates
// A date is, at it's core, just a timestamp from Jan 1, 1970 UTC (the UNIX Epoch)
How Date is interpreted
Okay so. Dates are just a timestamp number. Or you know, they are a whole class, but, at the core of the date itself like some big onion, they have a timestamp which is the milliseconds since Unix Epoch.
There are always two ways to interpret any timezone - as local time or as UTC.
The ISO 8601 date format
Also just called ISO
In UTC: 2024-12-04T20:48:17Z
With an offset: 2024-12-04T08:48:17−12:00
So its like
<year>-<month>-<day>T<hour>:<minutes>:<seconds>:<optional ms>Z
Let me try
2024-12-04T5:05:24-5:00
It’s not daylight’s savings time and I’m on the east coast, so I am in EST, which is UTC-05:00.
Note how in the ISO 8601 date format, the month comes before the day. I feel like that’s the most opinionated thing about it (and yes Americans are wrong to order it differently - I’m not saying it’s a bad opinion).
More Timezone stuff
getTimezoneOffset() - this method returns the difference between the UTC and local time in minutes. I think this depends on the operating system to know what the offset is though.
If I do this right now I get 300, which is the equivalent of 5 hours. Nice! That is. Correct.
So although time is always stored internally as UTC
Note that right now, writing this, I'm in EST
And it's 5:39PM, December 4th in NYC
toISOString()
2024-12-04T22:37:47.340Z
toUTCString()
Wed, 04 Dec 2024 22:37:47 GMT
getUTCHours()
22
toLocaleString()
The Intl.DateTimeFormat
Wait what is this?
Huh okay so it’s a global object. That enables formatting. Cool.
Limitations of the Native Date Library
- Assumes either local system timezone or UTC, so you can’t specify geographic timezones.
- If you need to convert times between timezones, you can’t.
- Parsing of datetime strings (like ones that aren’t ISO 8601) doesn’t always work
- There are problems with some of the date math, like adding a month to January 31st not accounting for variable month lengths. Date arithmetic in general is sort of cumbersome
- Limited formatting options
I guess this stuff happens if you don’t trust system time though, right?
Daylight’s Savings
I’m just gonna get this stuff straight right now. Daylight’s savings is a stupid event that starts on the second sunday of March in which clocks are set one hour ahead of “normal” time. If you live on the east coast for example, normal time or standard time, is at a -5, or UTC-05:00.
This means that during standard time, our clocks are 5 hours behind those in the UTC timezone, renamed for Universal Coordinated Time, and the reason that the letters are out of order is because it was some compromise with the french, who also wanted to use those letter because it makes sense in french to say temps coordonné universel. I guess that the compromise particularly worked out because neither universal coordinated time nor temps coordonné universel can be directly turned into the acronym UTC so we can all be confused equally.
It used to be called Greenwich time because, I dunno, I think the first person to be like how do I know if the time the train arrives is in my time or yours? was some Brit living in Greenwich who was concerned enough to start beginning to standardize time to begin with, which used to be super locally and then, before that, didn’t really exist as we know today.
For reasons I don’t really understand UTC time can also be referred to as Zulu time, and it is, which is why an ISO 8601 formatted timestamp ends in a Z. This is to denote that it is not local time, so if you want that you’ll need to do the offset yourself.
That said, if a timestamp has no Z or offset or any other sort of metadata connected to it, it’s sort of ambiguous. Is it UTC? Is it EST? Is it EDT? Right! We were talking about daylight’s savings.
When I first learned about daylight’s savings as a six year old on their way to school (and I definitely didn’t ask by the way, I barely knew what time was back then and probably had a concept of it more akin to the dark ages, or living in a jungle)
My mom told me that daylight’s savings time was created so that farmer’s had more time to work in the winter. Or something like this. This is one of those half-remembered truths/facts/ideas that stuck around in my brain and tended to make me more confused than anything whenever I thought about it.
I think the best version of this idea is that, in the winter…you know what, I’m not even going to go into it because I can’t think of a way this makes sense, and also, I don’t think this is true. The real reason makes more sense.
Apparently in WWI, the US or idk somebody, didn’t have as much fuel to burn as they wanted. And it was summertime. And someone said, hey look, if we just changed the clocks to be later, then people would “have more daylight”, since during the summer months you can get away with the same hour actually pointing to a later point in the day, and that point in the day will still have daylight. Like, idk, 7. 7 was pointing to 7 and someone said, that’s a waste, 7 should point to what is now 8, and then people would go to bed earlier, which would have the effect of them getting up later, and then they wouldn’t burn so much fuel in the morning when it’s dark because the daylight hours now line up better with the hours that correspond to being awake.
This doesn’t really make a whole lot of sense to me either though, since…why wouldn’t people just be getting up when the sun came out? Or jobs starting during that time? Or whatever? I mean, if this is true, it would have been equally effective to not change the time and to just tell people yo, get up a bit later. Don’t make people go to work so early, they are burning all the fuel why they are brushing their teeth.
So forget that two. Story 2 sounds like nonsense as well.
Maybe the best story is that there is no good reason we did this terrible confusing thing, but here are the facts-
Second sunday of March, what was known as 7pm in EDT is now referred to as 8pm is EST. Because EST has a -4 offset relative to UTC while EDT the quote on quote normal one, has a -5 hour offset to UTC, while UTC, being also known as zulu time, never changes because it is the standard by which we all set our watches in relation to and if it were to be variable we would all lose our minds and planes would collide in midair.
I find there are two easy-ish ways that help me grok this
- EST (eastern standard time) is always
UTC-5, and EDT is alwaysUTC-4. All daylight’s savings time is is this coordinated decision to flip flop timezones together once a year. In theory, you could probably start a movement to just stop doing this and refuse to use EDT, and no one could stop you. EDT is still there, it’s just not being used for most of the year. - Thinking of these time zones as windows. The sun is, of course, doing what it always does. Its trajectory will be the same, going through the same points regardless of the numbers we assign to the checkpoints. I sort of like to think of the natural window of daylight being the original anchor point of a timezone, and then things like EDT or EST are more abstract windows superimposed upon this circadian pattern.
Oh yeah another thing I want to point out - Standard Time is actually used the minority of the time. Standard time is used from the first Sunday on November 3rd at 2am local time until that second Sunday in March. So we only have it 4 months out of the year on the east coast. I think it’s different in other places. This confuses me, because you’d think the ‘standard’ thing would happen the majority of the time, but doesn’t.
Great book about time by the way: Four Thousand Weeks: A Mortal’s Guide to Time Management by Oliver Burkeman, which talks a bit about the history of time, the different experiences of time, and the commodification of time.
So yup, that’s daylight’s savings!