Keeping track of time is complicated for programmers due to leap seconds, timezones, and the weirdly designed Gregorian calendar. A new bill is going through congress to make daylight savings time permanent - here's what that could mean for developers. 

#compsci #programming #TheCodeReport

🔗 Resources

Daylight Savings Bill https://www.reuters.com/world/us/us-senate-approves-bill-that-would-make-daylight-savings-time-permanent-2023-2022-03-15/
Try the Temporal API https://tc39.es/proposal-temporal/docs/
Why JS Dates Suck https://maggiepint.com/2017/04/09/fixing-javascript-date-getting-started/

🔥 Get More Content - Upgrade to PRO

Upgrade to Fireship PRO at https://fireship.io/pro
Use code lORhwXd2 for 25% off your first payment. 

🎨 My Editor Settings

- Atom One Dark 
- vscode-icons
- Fira Code Font

🔖 Topics Covered

- How do timezones work?
- What is a 13 month calendar?
- What is the Gregorian calendar?
- Timezones explained for programmers
- How to use JavaScript Temporal API
- What are the most hated features in JavaScript?
2024-02-04T13:39:03.151Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
0dc6194c-ee1e-4067-b8d4-57a3c3fc50d8
750046e2880d201812d7202ad64e4209a6d2be7c9d90af4fd438224d45e78674
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
It is March 17, 2022, and you're watching the Code Report.
It's about time we had a talk about time.
You would think it's a pretty simple concept.
Time began on January 1, 1970 with the UNIX epoch.
At any moment, we can get the number of milliseconds elapsed from this date on any computer using a method like date now.
This is called incremental time, but one problem is that the Earth doesn't rotate evenly because it's actually flat, and the International Earth Rotation Service occasionally mandates a leap second, where an additional second is added to the last minute of the day.
Things start getting weird when we talk about time zones, which are calculated relative to Greenwich Mean Time.
On the Pacific, we subtract 8 hours.
But in Newfoundland, they only subtract 3 and a half hours.
And in Nepal, they add 5 3 quarters.
Then daylight savings comes around and all the time zones change, except in places like Arizona and Hawaii that don't do a time change.
In the South Pacific, they're 13 hours ahead, which requires them to skip an entire day.
You could celebrate New Year's on Christmas Island, spend the entire next day recovering from your over, then fly to Jarvis Island in time to celebrate New Year's Eve again.
Now, when it comes to the entire year, the Gregorian calendar is a ridiculous abstraction.
Some months have 28 days, well, others have 31.
But every other counting system we use, like weeks days, have consistent intervals.
It doesn't have to be this way.
The Cotswirth plan, which was presented in 1902, divides the year into 13 months, each month with 4 weeks or 28 days, with one rest day somewhere in the middle.
It makes so more sense and aligns better with the lunar cycle.
For developers, it would make the complicated matter of finding the duration of multiple months a simple matter of multiplying by 28, but there may be some good news when it comes to keeping track of time.
There's a bill going through congress right now to get rid of daylight savings.
Honestly, it doesn't go far enough and I wish they would also get rid of the Gregorian calendar.
This could be bad news though for low level systems programmers who figured out all these weird rules with time zones.
I imagine this is the type of code that nobody wants to touch, but if we get rid of daylight savings, somebody will have to go in there and change things.
Speaking of changes, there is a stage 3 proposal so for the temporal API in JavaScript, which would make it much easier to work with dates and times.
The current date implementation in JavaScript goes all the way back to 1990 5 when Brendan Eich had 10 days to write the language.
The overlords at Netscape wanted it to be kind of like Java, so he copied the Java implementation, which for lack of a better word, was a total piece of even Java overhauled that API back in 97, but in JavaScript, we still have the pleasure of using it.
And not surprisingly, recent polling data indicates that it's one of the most hated features in JavaScript.
There are libraries like moment.
Js and date functions that improve many of its shortcomings, but would be nice to have something better built in.
When getting the current time in JavaScript, it only gives you the milliseconds.
However, the new API would also give you microseconds, nanoseconds, and other formats that you might find useful.
An even bigger problem though is that it's difficult to compute times for a specific time zone, but the temporal API would fix that by providing a time zone aware object.
It would also make it much easier to compute values between dates and simplifies the process of working with dates in a variety of different ways.
Looks awesome, but I'm afraid we've run out of time for our session today.
This has been the Code Report.
Thanks for watching, and I will see you in the next one.

Speaker 0: It is March 17, 2022, and you're watching the Code Report. It's about time we had a talk about time. You would think it's a pretty simple concept. Time began on January 1, 1970 with the UNIX epoch. At any moment, we can get the number of milliseconds elapsed from this date on any computer using a method like date now.

This is called incremental time, but one problem is that the Earth doesn't rotate evenly because it's actually flat, and the International Earth Rotation Service occasionally mandates a leap second, where an additional second is added to the last minute of the day. Things start getting weird when we talk about time zones, which are calculated relative to Greenwich Mean Time. On the Pacific, we subtract 8 hours. But in Newfoundland, they only subtract 3 and a half hours. And in Nepal, they add 5 3 quarters.

Then daylight savings comes around and all the time zones change, except in places like Arizona and Hawaii that don't do a time change. In the South Pacific, they're 13 hours ahead, which requires them to skip an entire day. You could celebrate New Year's on Christmas Island, spend the entire next day recovering from your over, then fly to Jarvis Island in time to celebrate New Year's Eve again. Now, when it comes to the entire year, the Gregorian calendar is a ridiculous abstraction. Some months have 28 days, well, others have 31.

But every other counting system we use, like weeks days, have consistent intervals. It doesn't have to be this way. The Cotswirth plan, which was presented in 1902, divides the year into 13 months, each month with 4 weeks or 28 days, with one rest day somewhere in the middle. It makes so more sense and aligns better with the lunar cycle. For developers, it would make the complicated matter of finding the duration of multiple months a simple matter of multiplying by 28, but there may be some good news when it comes to keeping track of time.

There's a bill going through congress right now to get rid of daylight savings. Honestly, it doesn't go far enough and I wish they would also get rid of the Gregorian calendar. This could be bad news though for low level systems programmers who figured out all these weird rules with time zones. I imagine this is the type of code that nobody wants to touch, but if we get rid of daylight savings, somebody will have to go in there and change things. Speaking of changes, there is a stage 3 proposal so for the temporal API in JavaScript, which would make it much easier to work with dates and times.

The current date implementation in JavaScript goes all the way back to 1990 5 when Brendan Eich had 10 days to write the language. The overlords at Netscape wanted it to be kind of like Java, so he copied the Java implementation, which for lack of a better word, was a total piece of even Java overhauled that API back in 97, but in JavaScript, we still have the pleasure of using it. And not surprisingly, recent polling data indicates that it's one of the most hated features in JavaScript. There are libraries like moment. Js and date functions that improve many of its shortcomings, but would be nice to have something better built in.

When getting the current time in JavaScript, it only gives you the milliseconds. However, the new API would also give you microseconds, nanoseconds, and other formats that you might find useful. An even bigger problem though is that it's difficult to compute times for a specific time zone, but the temporal API would fix that by providing a time zone aware object. It would also make it much easier to compute values between dates and simplifies the process of working with dates in a variety of different ways. Looks awesome, but I'm afraid we've run out of time for our session today.

This has been the Code Report. Thanks for watching, and I will see you in the next one.
It is March 17, 2022, and you're watching the Code Report. It's about time we had a talk about time. You would think it's a pretty simple concept.
Time began on January 1, 1970 with the UNIX epoch. At any moment, we can get the number of milliseconds elapsed from this date on any computer using a method like date now. This is called incremental time, but one problem is that the Earth doesn't rotate evenly because it's actually flat, and the International Earth Rotation Service occasionally mandates a leap second, where an additional second is added to the last minute of the day. Things start getting weird when we talk about time zones, which are calculated relative to Greenwich Mean Time.
earth
On the Pacific, we subtract 8 hours. But in Newfoundland, they only subtract 3 and a half hours. And in Nepal, they add 5 3 quarters. Then daylight savings comes around and all the time zones change, except in places like Arizona and Hawaii that don't do a time change.
In the South Pacific, they're 13 hours ahead, which requires them to skip an entire day. You could celebrate New Year's on Christmas Island, spend the entire next day recovering from your over, then fly to Jarvis Island in time to celebrate New Year's Eve again. Now, when it comes to the entire year, the Gregorian calendar is a ridiculous abstraction. Some months have 28 days, well, others have 31. But every other counting system we use, like weeks days, have consistent intervals. It doesn't have to be this way. The Cotswirth plan, which was presented in 1902, divides the year into 13 months, each month with 4 weeks or 28 days, with one rest day somewhere in the middle.
holidays
christmas
vacation
seasons
easter
It makes so more sense and aligns better with the lunar cycle. For developers, it would make the complicated matter of finding the duration of multiple months a simple matter of multiplying by 28, but there may be some good news when it comes to keeping track of time. There's a bill going through congress right now to get rid of daylight savings.
cosmology
Honestly, it doesn't go far enough and I wish they would also get rid of the Gregorian calendar. This could be bad news though for low level systems programmers who figured out all these weird rules with time zones. I imagine this is the type of code that nobody wants to touch, but if we get rid of daylight savings, somebody will have to go in there and change things. Speaking of changes, there is a stage 3 proposal so for the temporal API in JavaScript, which would make it much easier to work with dates and times. The current date implementation in JavaScript goes all the way back to 1990 5 when Brendan Eich had 10 days to write the language. The overlords at Netscape wanted it to be kind of like Java, so he copied the Java implementation, which for lack of a better word, was a total piece of even Java overhauled that API back in 97, but in JavaScript, we still have the pleasure of using it. And not surprisingly, recent polling data indicates that it's one of the most hated features in JavaScript. There are libraries like moment. Js and date functions that improve many of its shortcomings, but would be nice to have something better built in. When getting the current time in JavaScript, it only gives you the milliseconds. However, the new API would also give you microseconds, nanoseconds, and other formats that you might find useful. An even bigger problem though is that it's difficult to compute times for a specific time zone, but the temporal API would fix that by providing a time zone aware object. It would also make it much easier to compute values between dates and simplifies the process of working with dates in a variety of different ways. Looks awesome, but I'm afraid we've run out of time for our session today. This has been the Code Report. Thanks for watching, and I will see you in the next one.
It is March 17, 2022, and you're watching the Code Report. It's about time we had a talk about time. You would think it's a pretty simple concept. Time began on January 1, 1970 with the UNIX epoch. At any moment, we can get the number of milliseconds elapsed from this date on any computer using a method like date now. This is called incremental time, but one problem is that the Earth doesn't rotate evenly because it's actually flat, and the International Earth Rotation Service occasionally mandates a leap second, where an additional second is added to the last minute of the day. Things start getting weird when we talk about time zones, which are calculated relative to Greenwich Mean Time. On the Pacific, we subtract 8 hours. But in Newfoundland, they only subtract 3 and a half hours. And in Nepal, they add 5 3 quarters. Then daylight savings comes around and all the time zones change, except in places like Arizona and Hawaii that don't do a time change. In the South Pacific, they're 13 hours ahead, which requires them to skip an entire day. You could celebrate New Year's on Christmas Island, spend the entire next day recovering from your over, then fly to Jarvis Island in time to celebrate New Year's Eve again. Now, when it comes to the entire year, the Gregorian calendar is a ridiculous abstraction. Some months have 28 days, well, others have 31. But every other counting system we use, like weeks days, have consistent intervals. It doesn't have to be this way. The Cotswirth plan, which was presented in 1902, divides the year into 13 months, each month with 4 weeks or 28 days, with one rest day somewhere in the middle. It makes so more sense and aligns better with the lunar cycle. For developers, it would make the complicated matter of finding the duration of multiple months a simple matter of multiplying by 28, but there may be some good news when it comes to keeping track of time. There's a bill going through congress right now to get rid of daylight savings. Honestly, it doesn't go far enough and I wish they would also get rid of the Gregorian calendar. This could be bad news though for low level systems programmers who figured out all these weird rules with time zones. I imagine this is the type of code that nobody wants to touch, but if we get rid of daylight savings, somebody will have to go in there and change things. Speaking of changes, there is a stage 3 proposal so for the temporal API in JavaScript, which would make it much easier to work with dates and times. The current date implementation in JavaScript goes all the way back to 1990 5 when Brendan Eich had 10 days to write the language. The overlords at Netscape wanted it to be kind of like Java, so he copied the Java implementation, which for lack of a better word, was a total piece of even Java overhauled that API back in 97, but in JavaScript, we still have the pleasure of using it. And not surprisingly, recent polling data indicates that it's one of the most hated features in JavaScript. There are libraries like moment. Js and date functions that improve many of its shortcomings, but would be nice to have something better built in. When getting the current time in JavaScript, it only gives you the milliseconds. However, the new API would also give you microseconds, nanoseconds, and other formats that you might find useful. An even bigger problem though is that it's difficult to compute times for a specific time zone, but the temporal API would fix that by providing a time zone aware object. It would also make it much easier to compute values between dates and simplifies the process of working with dates in a variety of different ways. Looks awesome, but I'm afraid we've run out of time for our session today. This has been the Code Report. Thanks for watching, and I will see you in the next one.
It
it
is
is
March
march
17,
17
2022,
2022
and
and
you're
you're
watching
watching
the
the
Code
code
Report.
report
It's
it's
about
about
time
time
we
we
had
had
a
a
talk
talk
about
about
time.
time
You
you
would
would
think
think
it's
it's
a
a
pretty
pretty
simple
simple
concept.
concept
Time
time
began
began
on
on
January
january
1,
1
1970
1970
with
with
the
the
UNIX
unix
epoch.
epoch
At
at
any
any
moment,
moment
we
we
can
can
get
get
the
the
number
number
of
of
milliseconds
milliseconds
elapsed
elapsed
from
from
this
this
date
date
on
on
any
any
computer
computer
using
using
a
a
method
method
like
like
date
date
now.
now
This
this
is
is
called
called
incremental
incremental
time,
time
but
but
one
one
problem
problem
is
is
that
that
the
the
Earth
earth
doesn't
doesn't
rotate
rotate
evenly
evenly
because
because
it's
it's
actually
actually
flat,
flat
and
and
the
the
International
international
Earth
earth
Rotation
rotation
Service
service
occasionally
occasionally
mandates
mandates
a
a
leap
leap
second,
second
where
where
an
an
additional
additional
second
second
is
is
added
added
to
to
the
the
last
last
minute
minute
of
of
the
the
day.
day
Things
things
start
start
getting
getting
weird
weird
when
when
we
we
talk
talk
about
about
time
time
zones,
zones
which
which
are
are
calculated
calculated
relative
relative
to
to
Greenwich
greenwich
Mean
mean
Time.
time
On
on
the
the
Pacific,
pacific
we
we
subtract
subtract
8
8
hours.
hours
But
but
in
in
Newfoundland,
newfoundland
they
they
only
only
subtract
subtract
3
3
and
and
a
a
half
half
hours.
hours
And
and
in
in
Nepal,
nepal
they
they
add
add
5
5
3
3
quarters.
quarters
Then
then
daylight
daylight
savings
savings
comes
comes
around
around
and
and
all
all
the
the
time
time
zones
zones
change,
change
except
except
in
in
places
places
like
like
Arizona
arizona
and
and
Hawaii
hawaii
that
that
don't
don't
do
do
a
a
time
time
change.
change
In
in
the
the
South
south
Pacific,
pacific
they're
they're
13
13
hours
hours
ahead,
ahead
which
which
requires
requires
them
them
to
to
skip
skip
an
an
entire
entire
day.
day
You
you
could
could
celebrate
celebrate
New
new
Year's
year's
on
on
Christmas
christmas
Island,
island
spend
spend
the
the
entire
entire
next
next
day
day
recovering
recovering
from
from
your
your
over,
over
then
then
fly
fly
to
to
Jarvis
jarvis
Island
island
in
in
time
time
to
to
celebrate
celebrate
New
new
Year's
year's
Eve
eve
again.
again
Now,
now
when
when
it
it
comes
comes
to
to
the
the
entire
entire
year,
year
the
the
Gregorian
gregorian
calendar
calendar
is
is
a
a
ridiculous
ridiculous
abstraction.
abstraction
Some
some
months
months
have
have
28
28
days,
days
well,
well
others
others
have
have
31.
31
But
but
every
every
other
other
counting
counting
system
system
we
we
use,
use
like
like
weeks
weeks
days,
days
have
have
consistent
consistent
intervals.
intervals
It
it
doesn't
doesn't
have
have
to
to
be
be
this
this
way.
way
The
the
Cotswirth
cotswirth
plan,
plan
which
which
was
was
presented
presented
in
in
1902,
1902
divides
divides
the
the
year
year
into
into
13
13
months,
months
each
each
month
month
with
with
4
4
weeks
weeks
or
or
28
28
days,
days
with
with
one
one
rest
rest
day
day
somewhere
somewhere
in
in
the
the
middle.
middle
It
it
makes
makes
so
so
more
more
sense
sense
and
and
aligns
aligns
better
better
with
with
the
the
lunar
lunar
cycle.
cycle
For
for
developers,
developers
it
it
would
would
make
make
the
the
complicated
complicated
matter
matter
of
of
finding
finding
the
the
duration
duration
of
of
multiple
multiple
months
months
a
a
simple
simple
matter
matter
of
of
multiplying
multiplying
by
by
28,
28
but
but
there
there
may
may
be
be
some
some
good
good
news
news
when
when
it
it
comes
comes
to
to
keeping
keeping
track
track
of
of
time.
time
There's
there's
a
a
bill
bill
going
going
through
through
congress
congress
right
right
now
now
to
to
get
get
rid
rid
of
of
daylight
daylight
savings.
savings
Honestly,
honestly
it
it
doesn't
doesn't
go
go
far
far
enough
enough
and
and
I
i
wish
wish
they
they
would
would
also
also
get
get
rid
rid
of
of
the
the
Gregorian
gregorian
calendar.
calendar
This
this
could
could
be
be
bad
bad
news
news
though
though
for
for
low
low
level
level
systems
systems
programmers
programmers
who
who
figured
figured
out
out
all
all
these
these
weird
weird
rules
rules
with
with
time
time
zones.
zones
I
i
imagine
imagine
this
this
is
is
the
the
type
type
of
of
code
code
that
that
nobody
nobody
wants
wants
to
to
touch,
touch
but
but
if
if
we
we
get
get
rid
rid
of
of
daylight
daylight
savings,
savings
somebody
somebody
will
will
have
have
to
to
go
go
in
in
there
there
and
and
change
change
things.
things
Speaking
speaking
of
of
changes,
changes
there
there
is
is
a
a
stage
stage
3
3
proposal
proposal
so
so
for
for
the
the
temporal
temporal
API
api
in
in
JavaScript,
javascript
which
which
would
would
make
make
it
it
much
much
easier
easier
to
to
work
work
with
with
dates
dates
and
and
times.
times
The
the
current
current
date
date
implementation
implementation
in
in
JavaScript
javascript
goes
goes
all
all
the
the
way
way
back
back
to
to
1990
1990
5
5
when
when
Brendan
brendan
Eich
eich
had
had
10
10
days
days
to
to
write
write
the
the
language.
language
The
the
overlords
overlords
at
at
Netscape
netscape
wanted
wanted
it
it
to
to
be
be
kind
kind
of
of
like
like
Java,
java
so
so
he
he
copied
copied
the
the
Java
java
implementation,
implementation
which
which
for
for
lack
lack
of
of
a
a
better
better
word,
word
was
was
a
a
total
total
piece
piece
of
of
even
even
Java
java
overhauled
overhauled
that
that
API
api
back
back
in
in
97,
97
but
but
in
in
JavaScript,
javascript
we
we
still
still
have
have
the
the
pleasure
pleasure
of
of
using
using
it.
it
And
and
not
not
surprisingly,
surprisingly
recent
recent
polling
polling
data
data
indicates
indicates
that
that
it's
it's
one
one
of
of
the
the
most
most
hated
hated
features
features
in
in
JavaScript.
javascript
There
there
are
are
libraries
libraries
like
like
moment.
moment
Js
js
and
and
date
date
functions
functions
that
that
improve
improve
many
many
of
of
its
its
shortcomings,
shortcomings
but
but
would
would
be
be
nice
nice
to
to
have
have
something
something
better
better
built
built
in.
in
When
when
getting
getting
the
the
current
current
time
time
in
in
JavaScript,
javascript
it
it
only
only
gives
gives
you
you
the
the
milliseconds.
milliseconds
However,
however
the
the
new
new
API
api
would
would
also
also
give
give
you
you
microseconds,
microseconds
nanoseconds,
nanoseconds
and
and
other
other
formats
formats
that
that
you
you
might
might
find
find
useful.
useful
An
an
even
even
bigger
bigger
problem
problem
though
though
is
is
that
that
it's
it's
difficult
difficult
to
to
compute
compute
times
times
for
for
a
a
specific
specific
time
time
zone,
zone
but
but
the
the
temporal
temporal
API
api
would
would
fix
fix
that
that
by
by
providing
providing
a
a
time
time
zone
zone
aware
aware
object.
object
It
it
would
would
also
also
make
make
it
it
much
much
easier
easier
to
to
compute
compute
values
values
between
between
dates
dates
and
and
simplifies
simplifies
the
the
process
process
of
of
working
working
with
with
dates
dates
in
in
a
a
variety
variety
of
of
different
different
ways.
ways
Looks
looks
awesome,
awesome
but
but
I'm
i'm
afraid
afraid
we've
we've
run
run
out
out
of
of
time
time
for
for
our
our
session
session
today.
today
This
this
has
has
been
been
the
the
Code
code
Report.
report
Thanks
thanks
for
for
watching,
watching
and
and
I
i
will
will
see
see
you
you
in
in
the
the
next
next
one.
one
success
The Code Report discusses the concept of time and how it can be confusing for low-level developers. There is a bill going through Congress to get rid of daylight savings, but it could be bad news for low-level systems developers. There is also a proposal to make it easier to work with dates and work with time zones in JavaScript, and a new clock proposal in Js and Date functions that improve some shortcomings. The report concludes that there is a lot of work left to do in creating a better code for us.
Time… a programmer's worst enemy // The Code Report
It is March 17, 2022, and you're watching the Code Report. It's about time we had a talk about time. You would think it's a pretty simple concept. Time began on January 1, 1970 with the UNIX epoch. At any moment, we can get the number of milliseconds elapsed from this date on any computer using a method like date now. This is called incremental time, but one problem is that the Earth doesn't rotate evenly because it's actually flat, and the International Earth Rotation Service occasionally mandates a leap second, where an additional second is added to the last minute of the day. Things start getting weird when we talk about time zones, which are calculated relative to Greenwich Mean Time. On the Pacific, we subtract 8 hours. But in Newfoundland, they only subtract 3 and a half hours. And in Nepal, they add 5 3 quarters. Then daylight savings comes around and all the time zones change, except in places like Arizona and Hawaii that don't do a time change. In the South Pacific, they're 13 hours ahead, which requires them to skip an entire day. You could celebrate New Year's on Christmas Island, spend the entire next day recovering from your over, then fly to Jarvis Island in time to celebrate New Year's Eve again. Now, when it comes to the entire year, the Gregorian calendar is a ridiculous abstraction. Some months have 28 days, well, others have 31. But every other counting system we use, like weeks days, have consistent intervals. It doesn't have to be this way. The Cotswirth plan, which was presented in 1902, divides the year into 13 months, each month with 4 weeks or 28 days, with one rest day somewhere in the middle. It makes so more sense and aligns better with the lunar cycle. For developers, it would make the complicated matter of finding the duration of multiple months a simple matter of multiplying by 28, but there may be some good news when it comes to keeping track of time. There's a bill going through congress right now to get rid of daylight savings. Honestly, it doesn't go far enough and I wish they would also get rid of the Gregorian calendar. This could be bad news though for low level systems programmers who figured out all these weird rules with time zones. I imagine this is the type of code that nobody wants to touch, but if we get rid of daylight savings, somebody will have to go in there and change things. Speaking of changes, there is a stage 3 proposal so for the temporal API in JavaScript, which would make it much easier to work with dates and times. The current date implementation in JavaScript goes all the way back to 1990 5 when Brendan Eich had 10 days to write the language. The overlords at Netscape wanted it to be kind of like Java, so he copied the Java implementation, which for lack of a better word, was a total piece of even Java overhauled that API back in 97, but in JavaScript, we still have the pleasure of using it. And not surprisingly, recent polling data indicates that it's one of the most hated features in JavaScript. There are libraries like moment. Js and date functions that improve many of its shortcomings, but would be nice to have something better built in. When getting the current time in JavaScript, it only gives you the milliseconds. However, the new API would also give you microseconds, nanoseconds, and other formats that you might find useful. An even bigger problem though is that it's difficult to compute times for a specific time zone, but the temporal API would fix that by providing a time zone aware object. It would also make it much easier to compute values between dates and simplifies the process of working with dates in a variety of different ways. Looks awesome, but I'm afraid we've run out of time for our session today. This has been the Code Report. Thanks for watching, and I will see you in the next one.
The Code Report discusses the concept of time and how it can be confusing for low-level developers. There is a bill going through Congress to get rid of daylight savings, but it could be bad news for low-level systems developers. There is also a proposal to make it easier to work with dates and work with time zones in JavaScript, and a new clock proposal in Js and Date functions that improve some shortcomings. The report concludes that there is a lot of work left to do in creating a better code for us.

        [INST]
        You are youtuber called Fireship you make engaging high-intensity and entertaining coding tutorials and tech news. 
        you covers a wide range of topics relevant to programmers, aiming to help them learn and improve their skills quickly.
        
        Given the title of the video : Time… a programmer's worst enemy // The Code Report 
        and a small summary : The Code Report discusses the concept of time and how it can be confusing for low-level developers. There is a bill going through Congress to get rid of daylight savings, but it could be bad news for low-level systems developers. There is also a proposal to make it easier to work with dates and work with time zones in JavaScript, and a new clock proposal in Js and Date functions that improve some shortcomings. The report concludes that there is a lot of work left to do in creating a better code for us.
        [/INST]
        
        Generate the video : It is March 17, 2022, and you're watching the Code Report. It's about time we had a talk about time. You would think it's a pretty simple concept. Time began on January 1, 1970 with the UNIX epoch. At any moment, we can get the number of milliseconds elapsed from this date on any computer using a method like date now. This is called incremental time, but one problem is that the Earth doesn't rotate evenly because it's actually flat, and the International Earth Rotation Service occasionally mandates a leap second, where an additional second is added to the last minute of the day. Things start getting weird when we talk about time zones, which are calculated relative to Greenwich Mean Time. On the Pacific, we subtract 8 hours. But in Newfoundland, they only subtract 3 and a half hours. And in Nepal, they add 5 3 quarters. Then daylight savings comes around and all the time zones change, except in places like Arizona and Hawaii that don't do a time change. In the South Pacific, they're 13 hours ahead, which requires them to skip an entire day. You could celebrate New Year's on Christmas Island, spend the entire next day recovering from your over, then fly to Jarvis Island in time to celebrate New Year's Eve again. Now, when it comes to the entire year, the Gregorian calendar is a ridiculous abstraction. Some months have 28 days, well, others have 31. But every other counting system we use, like weeks days, have consistent intervals. It doesn't have to be this way. The Cotswirth plan, which was presented in 1902, divides the year into 13 months, each month with 4 weeks or 28 days, with one rest day somewhere in the middle. It makes so more sense and aligns better with the lunar cycle. For developers, it would make the complicated matter of finding the duration of multiple months a simple matter of multiplying by 28, but there may be some good news when it comes to keeping track of time. There's a bill going through congress right now to get rid of daylight savings. Honestly, it doesn't go far enough and I wish they would also get rid of the Gregorian calendar. This could be bad news though for low level systems programmers who figured out all these weird rules with time zones. I imagine this is the type of code that nobody wants to touch, but if we get rid of daylight savings, somebody will have to go in there and change things. Speaking of changes, there is a stage 3 proposal so for the temporal API in JavaScript, which would make it much easier to work with dates and times. The current date implementation in JavaScript goes all the way back to 1990 5 when Brendan Eich had 10 days to write the language. The overlords at Netscape wanted it to be kind of like Java, so he copied the Java implementation, which for lack of a better word, was a total piece of even Java overhauled that API back in 97, but in JavaScript, we still have the pleasure of using it. And not surprisingly, recent polling data indicates that it's one of the most hated features in JavaScript. There are libraries like moment. Js and date functions that improve many of its shortcomings, but would be nice to have something better built in. When getting the current time in JavaScript, it only gives you the milliseconds. However, the new API would also give you microseconds, nanoseconds, and other formats that you might find useful. An even bigger problem though is that it's difficult to compute times for a specific time zone, but the temporal API would fix that by providing a time zone aware object. It would also make it much easier to compute values between dates and simplifies the process of working with dates in a variety of different ways. Looks awesome, but I'm afraid we've run out of time for our session today. This has been the Code Report. Thanks for watching, and I will see you in the next one.
        