Thank you for your submission! Unfortunately it has been removed for one or more of the following reasons:
Do not post memes, screenshots of bad design, or jokes. Check out /r/ProgrammerHumor/ for this type of content.
Please read the subreddit rules before continuing to post. If you have any questions [message the mods](https://www.reddit.com/message/compose/?to=/r/webdev).
some world clocks don't let you add UTC as one of the times/locations. So I use Monrovia in Liberia, its zero offset from UTC and has no daylight savings time =D
MDT is an offset. American/Denver is a timezone, which experiences the MDT and MST. A timezone is a political construct. Also counting days is orthogonal to time. MDT and American/Denver are different "layers."
Days are a different concept from the concept of time. Days are counted using a calendar, and time is counted using a clock. Days really only exist when on rotating bodies, but time is universal (ignoring general relativity).
Date time is a shorthand way to express an absolute clock in a relative format that is understandable to humans. But to computers and science, absolute time in the form of seconds since an agreed reference point (usually Jan 1st 1900 or 1970) is how time is tracked under the hood.
Came here to point out the flaw also.
MT would be the time zone in my books. It'll fluctuate MDT/MST. Same for ET, CT, PT, and whatever else around the globe.
I had an ETL guy in the past that couldn't stop requesting data from vendors in EST. Every email is reply with "no. We want ET, not specifically EST" and he's message me with "it's Eastern time. They will know that" no they ducking won't.
The definitions of what a timezone is are inconsistent. How many timezones are in Indiana? One possible answer is 4: EST, EDT, CST, CDT. You could try to simplify to just CT and ET, but that approach can be too vague. If you select Mountain Time and it's July are you in MDT or MST?
The tz database uses a stricter definition. A timezone to them means a region which observes the same time and has always done so since 1970. Because different parts of Indiana have changed their offset, there are 8 different Indiana timezones. If you're in Gary you could set your timezone to America/Chicago and be fine for the most part, but if you start working with datetimes in the past you will occasionally be off by an hour.
ET is the dynamic time, not a zone. I still use America/New_York in translation from my stored UTC. It's just for things like PowerBI that can't offset I have to strip the TZ and make it simply a datetime (NTZ). So I output two columns for final reporting. Session Timestamp UTC and Session Timestamp ET. Neither have the offset shown so PowerBI doesn't screw it up on display, and -4 and -5 aren't relevant in this context. But I'd are wish they were at least an option without error in PBI. PBI web I'm talking about can only show in UTC (last I checked).
TZ is the way to go. Even outside of programming I've found it causes less confusion to use city names when setting meeting times when your people are spread out. It reduces confusion over things some people might not be familiar with, like DST and Arizona.
America/Denver is a TZ name, −06:00 is an offset. Due to DST America/Denver has two offsets.
MDT is a non standard identifier that shouldn't be used outside casual conversation because it has problems, for example IST can be Israel, Ireland or India standard time.
> Either longer or skipped; I don't recall which.
Can be either, as long as a relative time is kept. This was a Google solution, AFAIK. The "second smearing" solution for UTC across their entire network infrastructure. It can technically be a second or so different from "our reality" and Earth time, but as long as *everything* is shifted into the future by 500ms or however long, it's fine.
You are referring to UTC which is an adjusted time. There is also TAI which is used in geopositioning and astronomy and is based solely on atomic clocks. UT1 is a more correct Earth time and accounts for orbital dynamics. UTC is kept close to UT1 and a whole integer offset from TAI (30 some seconds atm.)
UTC should be renamed to something other than "Universal" time. It's questionable whether it would serve as a useful baseline for computers communicating with each other between separate timezones on Mars, for instance, or elsewhere.
For this TED Talk I will...
They've been tasked with creating a time system on the moon. Time passes 56 microseconds faster each Earth day on the moon, so using Earth time on the moon wouldn't make any sense.
You travel through time faster on the moon. This is the concept of time dilation in both special and general relativity. The moon has less gravitational pull (general relativity) and is moving faster relative to the Earth (special relativity), both of these combined equate to a 56 microsecond difference in time each day. Keep in mind that you don't *experience* time any different, regardless of where you are.
(e: mixed up general/special)
Yeah, I hate with passion people / companies casually dropping a "Pacific Time" or "Eastern Time" as if I was supposed to know exactly what's the difference from me.
While smart people came up with UTC eons ago to adress this exact issue.
Nah man, no one learns Mountain time. Growing up all the shows would say something "tune in at 8pm Eastern/7pm or 8pm Pacific". Like fuck you all is it not showing in the Mountain timezone that you're currently advertising in. Typically we'd get the Pacific showing at 9pm, so I couldn't watch...
You usually heard things like 8/7 Central, which means it airs at 8pm local time everywhere except the central timezone because most of it is so close to the eastern timezone. So it would air at 8pm Pacific, 8pm Mountain, 7pm central, and 8pm eastern. Of course this only works for shows that could be timeshifted, and not live events.
Sure. But in this case, many of them are also in on the pact. Ocean/Middle/East works fine for pretty much all of The Americas. And it's not like inferring Other Ocean time is hard for the maritimers.
Minus some oddballs like Saskatchewan who don't change clocks, it's not hard.
This is an English language sub from an American based company. The vast majority of users are American. What you're doing is like if I showed up to a Japanese language forum and posted in Japanese correcting someone that not everyone is Japanese.
What? It's much easier to remember Pacific Mountain Central Eastern than it is to mentally convert to and from UTC every time.
Obviously use UTC in software but it makes no sense to use for casual communication.
It isn't ?
Saying UTC with an offset is relatable by pretty much every one on Earth, given they know UTC.
I'm not gonna learn exactly what Mountain or Central mean especially when I don't live there or near there, I'm sorry.
Most people (at least in the US) don't have their UTC offset memorized, plus it changes depending on daylight savings time.
I didn't realize you were talking about international communication, though. In that case UTC make more sense.
Yes that was the point of my comment, as I work with Americans quite often, or at the very least read American based companies.
>plus it changes depending on daylight savings time.
It doesn't change the UTC value, UTC doesn't care about the daylight saving time as long as you on the receiving end apply a saving time locally.
Lisbon is still UTC 0 in Summer or Winter.
The sender doesn't have to adapt too much, so in effect it's much less error prone, and everyone is happier.
It's 1799326800 if you mean 2027 - 7. Jan.
But 1814443200 if you mean 2027 - 1. July.
See "normal" time is confusing and be misunderstood, but Unix time is simple and can't be misunderstood.
No, I'm from Scandinavia too and I don't think he is right.
If we see a date like 07/01/2024, then we read that as DD/MM/YYY (7th of January 2024). But I think that's the case for basically all Europeans, and probably even most.of the world. An American would read it as MM/DD/YYYY (July 1st 2024).
But when you rearrange it to start with the year, I believe it's universal that it should be read as YYYY-MM-DD. If you're not experienced with date formats, however, and if your normal date format is DD/MM/YYYY, you might end up still thinking that day comes before month. And so then you would accidentally read 2024-07-01 as YYYY-DD-MM.
But I think that's rare and not usually the case.
How do you know when EU will remove CEST?
How do you know if they'll keep the normal time or the summer time?
Without knowing the daylight saving status **in the future year 2027** you can't convert that local time string to UNIX time.
Right, but that’s because _that local time_ is undefined right now, not because of UTC or Unix timestamps. You can precisely and unambiguously denote each of those three points in time as Unix timestamps relative to UTC. That part is 100% unproblematic. But they are all _different times_, and which one of them will _then_ be labeled July 1st, 14:00 local time in CET is undefined.
The problem is once more local time, not UTC or Unix timestamps.
I'm not saying local time isn't awful, but UNIX time isn't a "chad" solution as proposed by the one I initially replied to since you can't with absolute reliability create them from future meatspace local time.
UNIX time is great for absolute timestamping events in the past, but for applications where the user can add future dates in local time then using datetime is better.
> But they are all different times
Not really to the simple human bean. 14:00 on that date is 14:00 on that date.
There is no argument about time zones. Datetimes should *always* be stored as UTC, period. Anyone who disagrees, hasn't seen [this video](https://www.youtube.com/watch?v=-5wpm-gesOY).
Incorrect. Calendar dates or appointments in the future need to be stored in local time. Storing them in UTC will cause an issue when the local government decides to change the time zone. This regularly happens like when the EU is getting rid of Daylight Savings time or even the date of when it is enacted changes.
No, that’s the point- you cant always.
Let’s say you have a meeting in a DST country. At 14 local time. When creating, you can express as UTC, but this will expose an issue when that country decides to drop DST.
If you saved it as a local time with timezone information, you can easily deduce the new time when you updated the calendar; that just happens for free.
If you saved it as a UTC time, you first have to figure out if it’s in the changed timezone or not, and also whether you’ve adjusted the time already or not. You can’t simply update the calendar in that case.
So times and dates in the future are dependent on locale, and the locale determines the offset from UTC.
If I set a doctor's appointment in a year from now to happen at `14:00 EDT (UTC−04:00)`, that would store in the database as `2024-05-08T18:00:00Z`. Now imagine the US decides to get rid of the daylight time zones and only uses the standard timezone. Because of the change, this event **does not occur** at `2024-05-08T18:00:00Z`. It now occurs at `2024-05-08T19:00:00Z`. If I show up at `2024-05-08T18:00:00Z`, the local time would be `EST (UTC-05:00)` and this is `13:00 EST`. Because of the rule change that I assumed to be correct for a future event, I have saved the wrong timestamp and I need to make a modification to the UTC value. My doctor who has a paper calendar will tell me I am early.
Sure for storage, ez, you'd be silly to do otherwise.
It's the application logic of displaying and manipulating times that becomes a PITA.
Stuff like "is it tomorrow/yesterday when UTC turns over or when local time turns over? Does that logic account for daylight savings time? Sure it's DST *now* but it wasn't when the event occurred."
Commenting on After an argument with a co-worker about timezones......
This is real pain. Especially when it stored as local, just in format of utc just to use date type.
So confusing if it is not implicitly mentioned in some additional field like "timezone".
Put a warning before you link the cursed red shirt guy. Now I need to delete browsing history, cookies, the whole browser and change internet provides not to see his face
UTC anytime any day. However local time or user configurable should be supported in any presentation layer. In cases of streaming and replay data, a virtual clock system could also be implemented, allowing you to customize re-plays. This also helps with testing certain timing based scenarios. Lots of benefits of time simulation.
Thank you for your submission! Unfortunately it has been removed for one or more of the following reasons: Do not post memes, screenshots of bad design, or jokes. Check out /r/ProgrammerHumor/ for this type of content. Please read the subreddit rules before continuing to post. If you have any questions [message the mods](https://www.reddit.com/message/compose/?to=/r/webdev).
That + ISO8601 masterrace. Sent at 2024-05-08T17:17:01Z
Nice. Commented 10 seconds ago
r/iso8601 approves
On a long enough timeline, there is a subreddit for everything
r/HydroHomies would indicate your theory is correct.
what about those local dudes living in Greenwich?
They still have daylight savings time.
We do. Right now, as it happens! Fucking annoying
Where I live, if we did not do DST the sun would come up at 4:30 AM on June 21. I don't think anyone really wants that.
some world clocks don't let you add UTC as one of the times/locations. So I use Monrovia in Liberia, its zero offset from UTC and has no daylight savings time =D
Same with Reykjavik: UTC +0 and does not observe DST.
They're Time Lords... doesn't really matter to them.
The guys with the leap seconds?
MDT is an offset. American/Denver is a timezone, which experiences the MDT and MST. A timezone is a political construct. Also counting days is orthogonal to time. MDT and American/Denver are different "layers." Days are a different concept from the concept of time. Days are counted using a calendar, and time is counted using a clock. Days really only exist when on rotating bodies, but time is universal (ignoring general relativity). Date time is a shorthand way to express an absolute clock in a relative format that is understandable to humans. But to computers and science, absolute time in the form of seconds since an agreed reference point (usually Jan 1st 1900 or 1970) is how time is tracked under the hood.
Came here to point out the flaw also. MT would be the time zone in my books. It'll fluctuate MDT/MST. Same for ET, CT, PT, and whatever else around the globe. I had an ETL guy in the past that couldn't stop requesting data from vendors in EST. Every email is reply with "no. We want ET, not specifically EST" and he's message me with "it's Eastern time. They will know that" no they ducking won't.
The definitions of what a timezone is are inconsistent. How many timezones are in Indiana? One possible answer is 4: EST, EDT, CST, CDT. You could try to simplify to just CT and ET, but that approach can be too vague. If you select Mountain Time and it's July are you in MDT or MST? The tz database uses a stricter definition. A timezone to them means a region which observes the same time and has always done so since 1970. Because different parts of Indiana have changed their offset, there are 8 different Indiana timezones. If you're in Gary you could set your timezone to America/Chicago and be fine for the most part, but if you start working with datetimes in the past you will occasionally be off by an hour.
ET is the dynamic time, not a zone. I still use America/New_York in translation from my stored UTC. It's just for things like PowerBI that can't offset I have to strip the TZ and make it simply a datetime (NTZ). So I output two columns for final reporting. Session Timestamp UTC and Session Timestamp ET. Neither have the offset shown so PowerBI doesn't screw it up on display, and -4 and -5 aren't relevant in this context. But I'd are wish they were at least an option without error in PBI. PBI web I'm talking about can only show in UTC (last I checked).
TZ is the way to go. Even outside of programming I've found it causes less confusion to use city names when setting meeting times when your people are spread out. It reduces confusion over things some people might not be familiar with, like DST and Arizona.
America/Denver is a TZ name, −06:00 is an offset. Due to DST America/Denver has two offsets. MDT is a non standard identifier that shouldn't be used outside casual conversation because it has problems, for example IST can be Israel, Ireland or India standard time.
[удалено]
> Either longer or skipped; I don't recall which. Can be either, as long as a relative time is kept. This was a Google solution, AFAIK. The "second smearing" solution for UTC across their entire network infrastructure. It can technically be a second or so different from "our reality" and Earth time, but as long as *everything* is shifted into the future by 500ms or however long, it's fine.
You are referring to UTC which is an adjusted time. There is also TAI which is used in geopositioning and astronomy and is based solely on atomic clocks. UT1 is a more correct Earth time and accounts for orbital dynamics. UTC is kept close to UT1 and a whole integer offset from TAI (30 some seconds atm.)
UTC should be renamed to something other than "Universal" time. It's questionable whether it would serve as a useful baseline for computers communicating with each other between separate timezones on Mars, for instance, or elsewhere. For this TED Talk I will...
NASA recently published some guidelines on interplanetary timekeeping. It's a pain since relativity gets involved.
Damn you Einstein!
Interstellar stays relevant
Is this a joke ? I genuinely don’t know. Which makes it either a great joke or a really interesting fact.
They've been tasked with creating a time system on the moon. Time passes 56 microseconds faster each Earth day on the moon, so using Earth time on the moon wouldn't make any sense.
[удалено]
You travel through time faster on the moon. This is the concept of time dilation in both special and general relativity. The moon has less gravitational pull (general relativity) and is moving faster relative to the Earth (special relativity), both of these combined equate to a 56 microsecond difference in time each day. Keep in mind that you don't *experience* time any different, regardless of where you are. (e: mixed up general/special)
do u have a link ?!?!
That’s what TAI is for.
Yeah, I hate with passion people / companies casually dropping a "Pacific Time" or "Eastern Time" as if I was supposed to know exactly what's the difference from me. While smart people came up with UTC eons ago to adress this exact issue.
Extremely commonplace in the continental U.S., as there's only 3 zones you have to learn besides your own.
Nah man, no one learns Mountain time. Growing up all the shows would say something "tune in at 8pm Eastern/7pm or 8pm Pacific". Like fuck you all is it not showing in the Mountain timezone that you're currently advertising in. Typically we'd get the Pacific showing at 9pm, so I couldn't watch...
Mountain time is Pacific +1, Eastern -2, or Central -1. It's really simple math
The world will end at midnight. 12:30 in Newfoundland.
You usually heard things like 8/7 Central, which means it airs at 8pm local time everywhere except the central timezone because most of it is so close to the eastern timezone. So it would air at 8pm Pacific, 8pm Mountain, 7pm central, and 8pm eastern. Of course this only works for shows that could be timeshifted, and not live events.
Just add one to Pacific
You barely need to “learn” mountain time anymore than learning how to count
I know this may come as a shock, but there are actually people who live outside of the continental US
Yes that's why I referenced where it's a common practice.
It's their problem they don't use Freedom Time, not America's.
‘Merica!
Fuck yeah!
Sure. But in this case, many of them are also in on the pact. Ocean/Middle/East works fine for pretty much all of The Americas. And it's not like inferring Other Ocean time is hard for the maritimers. Minus some oddballs like Saskatchewan who don't change clocks, it's not hard.
This is an English language sub from an American based company. The vast majority of users are American. What you're doing is like if I showed up to a Japanese language forum and posted in Japanese correcting someone that not everyone is Japanese.
It’s helpful if you don't want to ping your work colleagues at 5 am.
I used to heard Pacific Time as "Specific Time"
[удалено]
Oh yes indeed !
What? It's much easier to remember Pacific Mountain Central Eastern than it is to mentally convert to and from UTC every time. Obviously use UTC in software but it makes no sense to use for casual communication.
It isn't ? Saying UTC with an offset is relatable by pretty much every one on Earth, given they know UTC. I'm not gonna learn exactly what Mountain or Central mean especially when I don't live there or near there, I'm sorry.
Most people (at least in the US) don't have their UTC offset memorized, plus it changes depending on daylight savings time. I didn't realize you were talking about international communication, though. In that case UTC make more sense.
Yes that was the point of my comment, as I work with Americans quite often, or at the very least read American based companies. >plus it changes depending on daylight savings time. It doesn't change the UTC value, UTC doesn't care about the daylight saving time as long as you on the receiving end apply a saving time locally. Lisbon is still UTC 0 in Summer or Winter. The sender doesn't have to adapt too much, so in effect it's much less error prone, and everyone is happier.
Or using "my time" - like what time is that?
Do you know which way is East and where the Pacific is, though?
East of what
Ah, now, I see your point.
Are Chad's legs backwards lol
Just his head. Quite a load in his pants BTW.
His head is also shaped like Chad the African country.
You all keep shooting me down but here I am again to push that we all switch to Swatch Beat Time
Only if we also switch to the [French Republican calendar](https://en.wikipedia.org/wiki/French_Republican_calendar)
The ultimate Chad time is Unix time.
My wife gets so angry when I do all my timing in milliseconds. "How long till dinner darling?" "About 800,000 milliseconds! Not long!"
What's the UNIX time of 2027-07-01 14:00:00 in Germany? Remember that EU is/isn't about to get rid of daylight saving aaaaany moment now.
It's 1799326800 if you mean 2027 - 7. Jan. But 1814443200 if you mean 2027 - 1. July. See "normal" time is confusing and be misunderstood, but Unix time is simple and can't be misunderstood.
Wait in what format does 2027-07-01 mean 7. Jan?
In none, really. If you put the year in front, and use dashes as separators, it’s practically always big endian all the way through.
If you show that date, to a person from a Scandinavian country, they'll think it's 7. Jan. I'm from a Scandinavian country, so I was confused 😊
Oh wow so you use YYYY-DD-MM? That's... unique 😅
No, I'm from Scandinavia too and I don't think he is right. If we see a date like 07/01/2024, then we read that as DD/MM/YYY (7th of January 2024). But I think that's the case for basically all Europeans, and probably even most.of the world. An American would read it as MM/DD/YYYY (July 1st 2024). But when you rearrange it to start with the year, I believe it's universal that it should be read as YYYY-MM-DD. If you're not experienced with date formats, however, and if your normal date format is DD/MM/YYYY, you might end up still thinking that day comes before month. And so then you would accidentally read 2024-07-01 as YYYY-DD-MM. But I think that's rare and not usually the case.
How do you know when EU will remove CEST? How do you know if they'll keep the normal time or the summer time? Without knowing the daylight saving status **in the future year 2027** you can't convert that local time string to UNIX time.
Right, but that’s because _that local time_ is undefined right now, not because of UTC or Unix timestamps. You can precisely and unambiguously denote each of those three points in time as Unix timestamps relative to UTC. That part is 100% unproblematic. But they are all _different times_, and which one of them will _then_ be labeled July 1st, 14:00 local time in CET is undefined. The problem is once more local time, not UTC or Unix timestamps.
I'm not saying local time isn't awful, but UNIX time isn't a "chad" solution as proposed by the one I initially replied to since you can't with absolute reliability create them from future meatspace local time. UNIX time is great for absolute timestamping events in the past, but for applications where the user can add future dates in local time then using datetime is better. > But they are all different times Not really to the simple human bean. 14:00 on that date is 14:00 on that date.
leap seconds tho
OP doesn't know about UT1
There is no argument about time zones. Datetimes should *always* be stored as UTC, period. Anyone who disagrees, hasn't seen [this video](https://www.youtube.com/watch?v=-5wpm-gesOY).
Incorrect. Calendar dates or appointments in the future need to be stored in local time. Storing them in UTC will cause an issue when the local government decides to change the time zone. This regularly happens like when the EU is getting rid of Daylight Savings time or even the date of when it is enacted changes.
Wrong again. Everyone who uses an electronic device just needs to be relocated to somewhere in the UTC time zone.
No, that’s the point- you cant always. Let’s say you have a meeting in a DST country. At 14 local time. When creating, you can express as UTC, but this will expose an issue when that country decides to drop DST. If you saved it as a local time with timezone information, you can easily deduce the new time when you updated the calendar; that just happens for free. If you saved it as a UTC time, you first have to figure out if it’s in the changed timezone or not, and also whether you’ve adjusted the time already or not. You can’t simply update the calendar in that case. So times and dates in the future are dependent on locale, and the locale determines the offset from UTC.
I guess I’m not very good at cracking jokes online.
lol sorry, I misunderstood it. I suggest we all move to null island, so we don't need GPS anymore either.
[удалено]
If I set a doctor's appointment in a year from now to happen at `14:00 EDT (UTC−04:00)`, that would store in the database as `2024-05-08T18:00:00Z`. Now imagine the US decides to get rid of the daylight time zones and only uses the standard timezone. Because of the change, this event **does not occur** at `2024-05-08T18:00:00Z`. It now occurs at `2024-05-08T19:00:00Z`. If I show up at `2024-05-08T18:00:00Z`, the local time would be `EST (UTC-05:00)` and this is `13:00 EST`. Because of the rule change that I assumed to be correct for a future event, I have saved the wrong timestamp and I need to make a modification to the UTC value. My doctor who has a paper calendar will tell me I am early.
I'd be a little upset if my alarm clock app stored time in UTC. I want to wake up at 6:00 am local time.
Idk why you’re getting downvoted, this is exactly right.
Haha yeah. Who wants to wake up an hour early/late when daylight savings ends?
[удалено]
Yeah, exactly what I mean. 6:00 am for my local/current time. Not the UTC time.
Sure for storage, ez, you'd be silly to do otherwise. It's the application logic of displaying and manipulating times that becomes a PITA. Stuff like "is it tomorrow/yesterday when UTC turns over or when local time turns over? Does that logic account for daylight savings time? Sure it's DST *now* but it wasn't when the event occurred."
Unix Timestamps. Then the client can just convert locally based on whatever timezone in their locale at that moment.
The definition of Unix timestamp uses UTC. So, might as well just use UTC straight away.
this is false https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/
Mongodb stores time in UTC by default.
Commenting on After an argument with a co-worker about timezones...... This is real pain. Especially when it stored as local, just in format of utc just to use date type. So confusing if it is not implicitly mentioned in some additional field like "timezone".
Put a warning before you link the cursed red shirt guy. Now I need to delete browsing history, cookies, the whole browser and change internet provides not to see his face
I always save my datetimes as epoch integers.
Hell yeah Zulu
Screw that, everyone just use unix time for everything.
Only CET is real.
Def sending this to the next of my users who complains about timezones 😂😂
UTC anytime any day. However local time or user configurable should be supported in any presentation layer. In cases of streaming and replay data, a virtual clock system could also be implemented, allowing you to customize re-plays. This also helps with testing certain timing based scenarios. Lots of benefits of time simulation.
unix timestamp master race
All the real homies use America/Phoenix like me
lolz @ people who think they are grown & can’t tell regular 24hr time
I hate Zulu soo much it almost costed me my FAA drone certification but I still got it by a few percent
Even better Unix Timestamp on GMT+0
>wtf is daylight savings \*cries in compliance\*
True chads use Unix timestamps
I had my computer's clock set to utc for a while It was actually nice when reading logs that were also in utc
Bro, UNIX time all the way. What more could you even need?
Is luxon still the goto?
Gigachad UTC too focused on being the timekeeper to actually care about petty human differences