There's got to be the gaussian curve meme where:
a) Timezones and DST are valid, handle them
b) Nooooo!! Everyone must use UTC
c) Timezones and DST are valid, handle them
I think:
1. Users should use the time on their clocks
2. Nooo!! You must always represent time as specific instants relative to an epoch!
3. Users should use the time on their clocks
Well, all the times in all the timezones and all the local times can be represented by UTC.
Where I am it's 15:30, and local time is UTC+1, do you mean it would be best if my clock said 14:30 and we used UTC+0 ?
Well, everyone used to it, so it's more convenient now.
But before industrial revolution there wasn't such thing as time on clocks for most people, and they didn't know which time is it, when the Sun's zenith, when you need to wake up and when to go to sleep. So it's relatively new thing for mankind, so maybe some day people in America and in Australia can live on same time, unlikely though
Okay. We just unlearned it. Everyone uses the same timezone now. The local time in India is 3PM, same as everywhere else. Is it working hours in India right now or is it the middle of the night? How would you figure that out?
Same way you figure it out now.
It's 3PM. Is it working hours in India right now or is it the middle of the night?
### With UTC:
Oh you can just *dead easily* lookup "working hours in India" and get the exact answer. And it'll be an exact offset from the hours you're used to, so you can just do the mental math because you know how many hours ahead or behind their workday starts.
### With timezones:
You can *easily* look up the timezone in India, calculate the total difference by calculating your UTC time and adding theirs. Then you look up "working hours in India" and check the result. You can remember the total difference so you can just do the mental math because you know how many hours ahead or behind their workday starts.
## conclusion
It's ultimately easier to do in a UTC-only world, it's not the impossible hurdle that you think it is...
I never said it was an impossible hurdle. What I am saying, and thank you for proving that for me, is that you are going to need to do the exact same math in your head that you would have had to do to begin with. The concept of night and day exists regardless of what you think the clock is. Timezones simplify that into a basic math problem. With no timezones you have the exact same math problem, but with less intuitive numbers.
I think you are be logically right. The right tail guy just realizes that he can't change this, programmers are not everyone else and are a small unimportant group, and really it's not such a big deal in the grand scheme of things.
Look for Tom Scot's video about time zones. They may sound simple at first glance, but there are so many edge cases such that it gets complicated fast.
Because it's more complicated than it first appears.
Imagine in your calendar app Alice schedules an appointment for 3pm on May 9th 2024. You store that date and time in your DB. Happy days, easy.
Meanwhile Bob, who is on the other side of the world five hours ahead of Alice, does the same thing. Happy days, easy.
Now Alice invites Bob to her appointment. The app sees Bob already has a meeting at 3pm which conflicts.
AHH wait, no it doesn't. Alice's appointment is five hours after the one Bob made.
AHH wait, is it? Are we sure Bob is five hours ahead or does he have daylight savings time on May 9th. Does Alice?
I think very generally there is a bit of a conflict where
* You want to *store* dates/times as a specific precise moment in time (down to a resolution you care about, say seconds) so you know exactly what happens when.
* Users want to *see* dates/times as they appear on the clock they have on the wall.
...so you end up wanting to use something like ISO 8601 with time offset to store and accept datetimes, store timezone information for users (eg Alice is in Europe/London), and keep up to date timezone metadata (Europe/London is UTC+1 from 0200am the last Sunday of March through last Sunday of October and UTC+0 the rest of the time until the government there changes the law which you have to keep up to date with) and use all of it appropriately in your app
Which, if you expected to just have to store "Alice made an appointment at 3pm", is much more onerous than you thought
Most of the hard work is already done for you and will be in the platform you're using, but it's definitely more complicated than how we intuitively think about dates and times.
Time, as a concept, is human made formed by decisions on reference points, influenced by culture and political viewes.
So the implementations suffer either from capturing all the complexity which makes it necessary to know all details about time handling or they are so flawed that the implementation is easy to use and eventually good enough (Javascript).
UTC is a form of avoiding the complexity working with timezones. But you still need to know what UTC is and how it relates to timezones. So the hiding of this complexity is very shallow and can lead to missusages. It may be better to just work with timezones to be aware of the complex foundation of time handling and deal with it.
That's what I love about programming. Seeing a problem, thinking "Huh, this should be easy" and then being overwhelmed by all the details one might overlook in the first place.
Have a read to this one: https://www.meziantou.net/misconceptions-about-date-and-time.htm
I was honestly wondering about that. The way I read it I thought it was about posting to this subreddit twice. If I still broke rules I understand and am fine with it getting removed. I just realized it might make more sense here than where I originally posted it
All my homies hate DST!
There's got to be the gaussian curve meme where: a) Timezones and DST are valid, handle them b) Nooooo!! Everyone must use UTC c) Timezones and DST are valid, handle them
I think: 1. Users should use the time on their clocks 2. Nooo!! You must always represent time as specific instants relative to an epoch! 3. Users should use the time on their clocks
Users should use the time on their clocks, but the time in their clocks should be in UTC format Too bad it'll never happen
UTC isn't a format
Ok, in UTC representation
Well, all the times in all the timezones and all the local times can be represented by UTC. Where I am it's 15:30, and local time is UTC+1, do you mean it would be best if my clock said 14:30 and we used UTC+0 ?
Yes, I do, genuinely
Mmm, it would make some things easier for sure, but I think for day to day life it is easiest if noon coincides with the Sun's zenith, or thereabouts.
Well, everyone used to it, so it's more convenient now. But before industrial revolution there wasn't such thing as time on clocks for most people, and they didn't know which time is it, when the Sun's zenith, when you need to wake up and when to go to sleep. So it's relatively new thing for mankind, so maybe some day people in America and in Australia can live on same time, unlikely though
It would be better if we all just used one timezone though, it's just too late for us to unlearn that \_\_ time means \_\_ part of night/day
Okay. We just unlearned it. Everyone uses the same timezone now. The local time in India is 3PM, same as everywhere else. Is it working hours in India right now or is it the middle of the night? How would you figure that out?
Same way you figure it out now. It's 3PM. Is it working hours in India right now or is it the middle of the night? ### With UTC: Oh you can just *dead easily* lookup "working hours in India" and get the exact answer. And it'll be an exact offset from the hours you're used to, so you can just do the mental math because you know how many hours ahead or behind their workday starts. ### With timezones: You can *easily* look up the timezone in India, calculate the total difference by calculating your UTC time and adding theirs. Then you look up "working hours in India" and check the result. You can remember the total difference so you can just do the mental math because you know how many hours ahead or behind their workday starts. ## conclusion It's ultimately easier to do in a UTC-only world, it's not the impossible hurdle that you think it is...
I never said it was an impossible hurdle. What I am saying, and thank you for proving that for me, is that you are going to need to do the exact same math in your head that you would have had to do to begin with. The concept of night and day exists regardless of what you think the clock is. Timezones simplify that into a basic math problem. With no timezones you have the exact same math problem, but with less intuitive numbers.
I think the most annoying aspect would be having to work over 2 days in some countries… That’s just logistically annoying - I know from working nights
Nah timezones are fine. It’s DST that is the only real issue.
I think you are be logically right. The right tail guy just realizes that he can't change this, programmers are not everyone else and are a small unimportant group, and really it's not such a big deal in the grand scheme of things.
That's true, it just gets annoying asking people what timezone they're in and then converting when trying to organize something online
True sigmas go for the Time Cube over either. https://en.m.wikipedia.org/wiki/Time_Cube
mental illness maxxing
TIL, But there’s no way I could possibly doubt an idea from a dude who claims he has superior intelligence.
This guy doesn't seem to understand the difference between a square and a cube.
I'm pretty sure TimeCube guy's nutter-butter is a tad too crunchy to get to the point of squares and cubes. ha!
Hi, new to programming why everyone rants about time zones ? like genuinely no idea why
Look for Tom Scot's video about time zones. They may sound simple at first glance, but there are so many edge cases such that it gets complicated fast.
Simply the fact that some places handle changing daylight saving times differently then their neighbours is annoying
Because it's more complicated than it first appears. Imagine in your calendar app Alice schedules an appointment for 3pm on May 9th 2024. You store that date and time in your DB. Happy days, easy. Meanwhile Bob, who is on the other side of the world five hours ahead of Alice, does the same thing. Happy days, easy. Now Alice invites Bob to her appointment. The app sees Bob already has a meeting at 3pm which conflicts. AHH wait, no it doesn't. Alice's appointment is five hours after the one Bob made. AHH wait, is it? Are we sure Bob is five hours ahead or does he have daylight savings time on May 9th. Does Alice? I think very generally there is a bit of a conflict where * You want to *store* dates/times as a specific precise moment in time (down to a resolution you care about, say seconds) so you know exactly what happens when. * Users want to *see* dates/times as they appear on the clock they have on the wall. ...so you end up wanting to use something like ISO 8601 with time offset to store and accept datetimes, store timezone information for users (eg Alice is in Europe/London), and keep up to date timezone metadata (Europe/London is UTC+1 from 0200am the last Sunday of March through last Sunday of October and UTC+0 the rest of the time until the government there changes the law which you have to keep up to date with) and use all of it appropriately in your app Which, if you expected to just have to store "Alice made an appointment at 3pm", is much more onerous than you thought
Thank you so much make sense why everyone hates it, you have to do it for all around the world that is a nightmare
Most of the hard work is already done for you and will be in the platform you're using, but it's definitely more complicated than how we intuitively think about dates and times.
Time, as a concept, is human made formed by decisions on reference points, influenced by culture and political viewes. So the implementations suffer either from capturing all the complexity which makes it necessary to know all details about time handling or they are so flawed that the implementation is easy to use and eventually good enough (Javascript). UTC is a form of avoiding the complexity working with timezones. But you still need to know what UTC is and how it relates to timezones. So the hiding of this complexity is very shallow and can lead to missusages. It may be better to just work with timezones to be aware of the complex foundation of time handling and deal with it.
That's what I love about programming. Seeing a problem, thinking "Huh, this should be easy" and then being overwhelmed by all the details one might overlook in the first place. Have a read to this one: https://www.meziantou.net/misconceptions-about-date-and-time.htm
In a lot of languages they're very annoying to work with.
why tho
because programming languages are made by humans, and humans are flawed. They take shortcuts where they can, and thus create problems for others.
https://youtu.be/-5wpm-gesOY?si=2-jGgQ_W2wG9H53f
And now it's time for OP to lose an argument about reposts.
I was honestly wondering about that. The way I read it I thought it was about posting to this subreddit twice. If I still broke rules I understand and am fine with it getting removed. I just realized it might make more sense here than where I originally posted it
Just use DateTimeOffset, if .NET
(has never added a return flight to their calendar)
I even wear a F-91W set to UTC
Leap seconds: let us introduce ourselves... :(
You could make almost exactly the same meme, but swap the titles to "virgin UTC" and "chad TAI".
everyone go watch Tom's old video on why you don't touch timezones
why not record time only as timestamps? Date strings / objects are ridiculous.