* India has half-hour timezones
* Countries change their DST rules all the time.
* Conversion between timezones is an utter mess.
As Wes McKinney once said about python datetime: "Welcome to Hell"[0]
* India has half-hour timezones
* Countries change their DST rules all the time.
* Conversion between timezones is an utter mess.
As Wes McKinney once said about python datetime: "Welcome to Hell"[0]
Not plural though;
The whole of India -- even though it is pretty vast in area -- has a single time-zone country-wide. I am very thankful for this. We already have a lot of other challenges -- including dozens of different languages -- that a single time zone is a relief.
But yes -- the +5:30 offset usually makes for a less-than-ideal factor to plan meetings or follow non local event schedules.
Did I mention we also hate the Summertime / Daylight Saving time adjustments we have to accommodate twice a year when working with western teams -- more adjustment even after most people have already sacrificed on a sane 9-5 schedule to ensure they overlap with EU/US teams for daily work meetings. We cant imagine why US that has multiple time-zones already in a single country, and EU whose countries are often smaller than states in India ... need so much adjustment. Why can't they, for instance, simply declare that school/offices open at 10am instead of 9am for six designated months every year instead of imposing this adjustment on the entire world.
If they did that, you'd still be stuck shifting your schedule when they change their working hours.
In the most simplest scenario -- once a recurring meeting is fixed at 10:30 AM eastern STANDARD time, say, -- no schedule change is needed all-year-long if we dont tamper with the clock.
It is just that US worker -- due to their own convenience -- decides to show up in their office at 9AM for six months and 10am for other other six months of the year. Recurring meeting does not need to change at all.
The adjustment , if any, is all on US side. And for local season / climate reasons which has nothing to do with the remote team members, and so the remote team members elsewhere in the world dont need to change anything at all.
Just dont tamper with the clock and things will be much more simple.
>> If they did that, you'd still be stuck shifting your schedule when they change their working hours.
No -- we do not want to link our meetings to the changing office hours. We just want a fixed time on a clock fixed clock. Pick a time that works throughout the year for both teams. Like 10.30 AM EST in my example above.
Current the meetings are "fixed time" but on a moving clock -- in reality the meetings shift around but US folks move their clocks to "simulate" for themselves that they are always having their daily meeting "at 10AM" -- they achieve this illusion by inflicting pain on themselves as well as rest of the world. We would love if they can leave us out of this forced dance :)
You're suggesting that twice every year, we change the times that retailers, offices, government agencies, broadway theaters, restaurants, roads, schools, and so on open and close. Schools alter class schedules and trains modify departure times. Also, we all reset our alarms, because we'll need to wake up at different times anyway.
It makes so much more sense to just change the clocks!
And yes, all of these things would need to change, because they all revolve around the typical work schedule! Parents bring children to school before heading to work. Public transit runs more frequently during rush hour.
There is a discussion to be had about whether we should be shifting our schedules in the first place. But as long as we're shifting schedules, it makes so much more sense to just change the damn clocks!
P.S. Most people don't have white collar jobs! Construction workers, janitors, mechanics and so on don't ever work across timezones.
P.P.S. I'm okay with nixing the time change as long as we don't end up on permanent daylights savings! However, permanent daylights savings is my nightmare.
Currently the shop closes at 8pm and it's dark by 4pm; in Summer it closes at 8pm still (on +1 time) and it's dark at what 11pm or later? Explain your point again?
If there is a certain time that really does work for everyone, then DST doesn't really affect it. At worse, it requires a bit of rescheduling in the calendar if the meeting was set by someone in a DST country. If the meeting was set by someone in India, it will even get automatically adjusted in everyone else's calendar. So DST itself is not actually making things difficult for you, it's only people's habits changing with winter/summer that makes things difficult.
And note, I have direct experience with all of this, working in Romania with colleagues from California and Kolkata with at least three recurring syncups with all three of us per week.
Outlook and calendar apps should probably make this a feature: "do not move this meeting for DST/summertime" (even if the host is in US/EU). Make it opt-in initially and a couple of years later make it opt-out (default) choice.
On a lighter note ... recurring meetings tagged to "dynamic time zones" should be allowed only after hosts "agree" to a disclaimer that they have consulted other participants and have their consent :D (a little like recording with two-party consent)
Because "The USA" spans from GMT+10 to GMT-10. Your Solar Noon only varies by an hour between Kolkata and Mumbai. Without time zones, the continental U.S. would see a solar noon difference of three and a half hours. And that's not including Alaska, Hawaii, and Guam, which gives us a 20 hour span. You want all those places to be in the same time zone?
Guam is a bit of an odd duck because it is on the other side of the date line. The US currently spans from UTC-4 in Puerto Rico to UTC+10 in Guam - which is essentially the same as UTC-14. That's a 10-hour span, not a 20-hour one. Still, excluding the minor overseas colonial possessions would probably make the most sense.
It's bizarre to suggest that someone in western Alaska should wake up at the same time as someone in Florida because that's what India does.
(And even though lining up a time with morning would be significantly more annoying and need to exclude the polar circles, I still wouldn't call it "impossible".)
If you want to know when the sun rises, sets, or is at its apex just look it up in a table. The former two vary unless you are very close to the equator anyway, and the latter is off by an hour for every country using "daylight saving time" for half the year. Never mind countries that span more than 1/24th of the globe but use a single timezone, and that isn't just China.
Also I don't really see how this is "for the convenience of the ruling elite". I'd be willing to bet money most people in Xinjiang wouldn't have this "problem" in their top ten. Probably not even top hundred. This seems like something you get used to once and then never think about again unless you travel or have a remote meeting.
Yes, a table.
A table with time.
A table that divides the world into zones with regard to time.
That definitely abolishes time zones.
> I'd be willing to bet money most people in Xinjiang wouldn't have this "problem" in their top ten.
Yeah, it probably does rank quite a bit below the genocide.
Anyway, time zones solve an important problem: People coordinate with other people close to them, but occasionally need to coordinate with other people far away. How do those far-away people know when the good times to call are? Clocks only work if you have some idea of what times mean in practice to distant people, which is greatly helped along by people setting their clocks to a local time that's known globally.
Think about it more. How sunrise and sunset change by location and by date.
A chart that covers both sunrise and sunset does not naturally have "zones", and any "zones" you try to infer would not resemble time zones at all. You're either looking at big sweeping ellipses, or you're dividing the world into hundreds of small tiles. It's not time zones.
I've been there and it was absolutely fine - a lot better than working in the US with its mess of timezones. Sure, the times in Xinjiang are "wrong" but who cares? I'll take getting up at "11AM" or whatever over having people in different offices think the meeting is an hour earlier or later and not finding out everyone was mixed up until it happens.
It's not hard to know when you do things where you live. Some places people drive on the left, some places they drive on the right, people in different places people speak different languages, people in different places get up and go to bed at different times. When you go to Xinjiang as an outsider sure the customary times are a bit unusual but they're far from the only unusual thing about going there.
> With time zones you know that businesses will work roughly from 9-10am to 5-6pm that people will normally go to bed around 10pm and will wake up around 7-8am.
Not necessarily - plenty of ways to be caught out if you make that kind of assumption about a place you're not familiar with (e.g. turning up at a business when it's siesta). When going somewhere unfamiliar you're already best off looking up when your hotel/restaurant/etc. opens, and it's easy to do these days.
Timezones maybe made sense when physically going to a different place was more common than having a phone/video meeting with someone in a different place. But nowadays being able to agree on the same instant in time when you're in two different places is more important and we should standardise.
Sure, it can work. It's just worse. It'll be harder to adapt to local time if you move there or go there to visit than just changing your clock to match local time. You'll need to convert constantly. What's the upside, though?
> Not necessarily - plenty of ways to be caught out if you make that kind of assumption about a place you're not familiar with (e.g. turning up at a business when it's siesta). When going somewhere unfamiliar you're already best off looking up when your hotel/restaurant/etc. opens, and it's easy to do these days.
Sure, you could still get things wrong, but you're suggesting going from a situation where it mostly works, to a situation where this never works.
>Timezones maybe made sense when physically going to a different place was more common than having a phone/video meeting with someone in a different place. But nowadays being able to agree on the same instant in time when you're in two different places is more important and we should standardise.
Timezones are the way we found to standardise once global commerce became a thing. Timezones give you essentially time and location, so it's easier to figure things out when multiple parties are involved.
No it isn't? You don't convert anything, you just do things at the times the locals do them. It's really not hard.
> What's the upside, though?
No changing clocks, no scheduling a meeting at the wrong time because you mixed up the timezones, no calling your parents and accidentally waking them up because it's the middle of the night for them.
> Timezones are the way we found to standardise once global commerce became a thing.
In the distant past each village had its own time; once the railways emerged and it was practical to go from place to place in the same day, we standardised time across decent-sized regions. Now that we can talk to people instantly around the world, it's time to contine that process and standardise time everywhere.
Before you get used to it, when you see a time you'll have no idea what time of the day it is. Is it early? Is it late? Is it during lunch time? You need to convert in your head "11am here means midnight where I come from, so that's actually really late". Very easy to forget and make a mistake.
> No changing clocks, no scheduling a meeting at the wrong time because you mixed up the timezones, no calling your parents and accidentally waking them up because it's the middle of the night for them.
huh? How is using a single time going to help with waking something up because it's the middle of the night for them? I'd say it's more likely. If someone is 6 hours behind you, you'll need to keep in mind that their 10am means what would be your 2am. Even though you both call it 10am, you would definitely not want to call them at 10am. If anything, that's more error prone and confusing.
That's not a real problem, IME. If someone invites you for lunch, it's going to be at lunch time. If someone wants to schedule a meeting, you have to check your calendar anyway.
> You need to convert in your head "11am here means midnight where I come from, so that's actually really late".
No, you don't. Converting in your head is the wrong approach just as it is for languages. Just get used to when you're going to bed and getting up. (And don't use AM/PM - why would you ever do that? Even within a single timezone it only causes confusion)
> How is using a single time going to help with waking something up because it's the middle of the night for them?
Because you never have to add or subtract a time, which is where most mistakes happen.
> If someone is 6 hours behind you, you'll need to keep in mind that their 10am means what would be your 2am. Even though you both call it 10am, you would definitely not want to call them at 10am.
Right, so you need to know when they go to sleep and when they get up, and not call them when they're asleep. But there's no arithmetic to get wrong, there's no risk of adding six hours instead of subtracting six hours or vice versa.
No, it spans from UTC-10 in Hawaii to UTC+10 in Guam. And if we include other US territories in the Pacific, like American Samoa, we have to include UTC-11. That's 21 hours.
95+% of Greenland's population lives on its west coast. The most common map projection one is likely to come across makes it look like that spans a pretty large longitude range but it actually only covers about 15°, a 1-hour span.
Take a look at a projection that does a better job of representing latitude, such as this [1] azimuthal equidistant projection and you can see that west coast Greenland is a lot more north/south than you might have expected based on the more usual projections.
Here's a map of the towns in Greenland with >300 population [2] showing how much more populated the west coast is than the rest of the country. If you add their populations and the populations of the towns listed in the table but too small to make the map it comes to about 3100 people.
[1] https://en.wikipedia.org/wiki/Azimuthal_equidistant_projecti...
[2] https://en.wikipedia.org/wiki/List_of_cities_and_towns_in_Gr...
I was not arguing for a single time zone.
you quoted only half of my sentence and are arguing against a strawman.
Shifting time-zones increases car accidents by about 6-16% for the entire week (studies vary). Just that is a massive enough impact on safety and productivity to discourage the switch. At a personal level, leaving work at 5.30-ish with it being pitch black outside, is among the most depressing things in the world. Even more wasteful is that the average American wakes up at 7.20am. So, they don't gain any daylight but lose an entire hour.
I'm not usually the type to make such accusations, so I apologize in advance for sounding culture-warry. But, switching-time zones is "white person thing". Large percent of the Chinese, Indian & the Middle Eastern population live above the 25th parallel (Florida) and large populations of Korea & Japan live north of the Bay Area without daylight-switching.
Permanent daylight time with later sunrise would be a huge win.
Are you aware the contiguous United States is three times larger than India? Alaska alone is half the size of India and not at the same longitude as the lower 48. Hawaii is even farther west than most of Alaska. The easternmost point in the US is 66 degrees west. The westernmost is 179 degrees west. That’s nearly a third of the globe and I'm not even including territories.
> Why can't they, for instance, simply declare that school/offices open at 10am instead of 9am for six designated months every year instead of imposing this adjustment on the entire world.
Is this a serious comment? Europe doesn’t have a central government. The most recent attempt to establish one was extremely unpopular and famously stopped in 1945.
Why should foreign schools and businesses change their hours to accommodate you? A more obvious solution would be to just stop observing DST but that’s not something that will happen unilaterally and will be an especially hard sell at extreme latitudes.
If you want to do business internationally you have to deal with timezones. India isn’t unique in that inconvenience.
Not unilaterally per se, but EU parliament did vote to end it in ... 2021 https://www.europarl.europa.eu/news/en/press-room/20190321IP... . COVID kind of put those plans on the backburner.
People at extreme latitudes should not care much, since for them DST does close to nothing.
The parent's proposal is actually quite sound. It would be a lot more useful to have institutions switch their starting times for part of the year when it makes sense for them, rather than forcing a one-size-fits-all solution on everyone. Countries at different latitudes would be free to switch e.g. school start times at different dates depending on when sunlight shifts too far in one direction, while keeping their clocks synchronised with astronomical time. Heck, Spain basically does that already, since they're on the wrong timezone (geography dictates they should be on British time, but because of events in the '40s, they're on Central European time) - so they do everything one hour "later".
This proposal is literally one-size-fits-all.
> It would be a lot more useful to have institutions switch their starting times for part of the year when it makes sense for them, rather than forcing a one-size-fits-all solution on everyone.
This is exactly how it works now. But there are a lot of institutions and they aren't coordinated.
you quoted half my sentence which creates an easy strawman.
> A more obvious solution would be to just stop observing DST
yes that is essentially my argument too ...with an extra accommodation for folks who will argue about seasons causing wild changes in sunrise / sunset / daylight.
Huh, why would it not happen unilaterally? Different countries already fiddle with their daylight savings times (or absence thereof) unilaterally, and the start of DST is not synchronised across the globe anyway.
So if you have two countries that start DST on different weeks that's already a hassle to deal with, and one of them going off DST altogether doesn't really add any extra hassle in their bilateral dealings.
that's one way to say it
For what it's worth, I've (British) never understood that either. Need more daylight hours for farmers to work or whatever, sure, no problem. But.. that's easily resolved as you described? And before widespread centralised time and access to it, surely they just started at sunrise or soon after, whenever the sun happened to rise. I don't get it.
Or, if you extrapolate this argument further, you could even wonder why the entire world can't run on a single timezone. Like, it can be UTC everywhere.
People in India can go to sleep at
Or, if you extrapolate this argument further, you could even wonder why the entire world can't run on a single timezone.
But here's the problem: for example, imagine it's UTC everywhere on Earth. No local timezones.
As per your solution, people in India can go to sleep at 4:30 pm (UTC), wake up at 12:30 am, have lunch at 7:30 am etc.
Likewise, people in San Francisco can go to bed at 6 am, wake up at 2 pm, have lunch at 9 pm etc.
Now, the problem is, when someone wants to setup an international meeting or whatever, nobody would have a clear idea or whether it would be "sleeping time" for any of the participants involved, without having to look it up.
Like, with the current setup, it's kind of universally understood that 3 am local time is sleeping time, hence people would avoid setting up meetings at that time.
But if everywhere on Earth it's the same time such as UTC, I would have no idea if 3 am UTC is your sleeping time or lunch time or whatever. I would have to maintain lookup tables of when the sleep time, lunch time etc would be for every country as per UTC.
Similar problems exist (to a lesser degree) when large countries move to a single timezone.
Yes there are flaws in the existing setup, but moving to a single timezone for large countries would only introduce a new set of challenges.
Kindly re-read.
I was arguing against daylight savings adjustments twice an year. Not against having multiple timezones per country / region. My comment was simply that timezones should be sufficient without the need for DST.
What I said ...
>> We cant imagine why US that has multiple time-zones already in a single country, and EU whose countries are often smaller than states in India ... need so much adjustment.
Simplified ...
>> cant imagine why US, and EU need so much adjustment.
Pardon any poor punctuation.
Planned local events: future date and time string including local time zone
Planned global events: future date and time string in UTC, with UTC timezone
Past events: date and time string in UTC with UTC time zone, unless there is a strong case to be made that these should be localized (see “planned local events” above)
Strings in the format specified by ISO-8601.
Of course, internal representation can be whatever it needs to be for efficiency. For example, maybe your database stores as integer microseconds since an epoch. Fine, but as soon as that leaves the database, ISO-8601 that date.
You should not convert the integer early, you should actually wait until the very last moment.
Nowadays a timestamp will be marshalled and demashalled by (at the very least) two runtimes until it reaches human eyeballs opening up a wide spectrum of bug potential, difficult to understand code and development slowdowns. Keeping it simple and unambiguous is very important. Time libraries have a habit of coming and going, ints are always there and 99% of the date arithmetic is trivial any way.
Don't use a lib, just pretty print numbers and you'll be fine.
You kinda have to guess from context that if it's a 10-digit number, it's probably seconds.
Also calculating amount of time between two ISO8601 strings without libraries is nor trivial, or any other operation actually. When dealing with dates, there is only one simple way to work with non-localized times, and it's not ISO-something.
EDIT:
> ...and what epoch and timezone to use.
This is also not correct. Unix timestamp has a well defined epoch and it doesn't deal with timezones (though the epoch itself is, of course, usually defined as 1970/01/01 00:00:00 UTC). You are free to define other timestamps, but unix timestamp is well defined.
Comprehension by extraterrestrial life is a localization problem.
You can store weight as ohms of resistance on a load cell. But if you want to share that data you need to either normalize the number to a mutually understood unit or provide detailed information about your scale.
Unix time has uniform handling over leap seconds, regardless of the precision.
A unix second is allowed to be different from a "real" elapsed second.
The unix day has 86400 "unix seconds" which are actually 86401 real seconds (for days with added leap seconds).
Any application logging real world events against unix time will screw up velocities, force, energy, etc when computing "instrument reading" per "unix second".
It might not matter to most people but it's an issue for surveyors, geophysicists, astrophysicists, engineers, etc.
That is a fair point for situations that depend on short term observations. But, UTC has the same issues there as Unix epoch. I think it is a valid edge case but if you are doing, say, GPS based speed calc I would wager you are already pulling your time reference from a low level source that you can depend on will be running steadily for the X minutes/hours you need it.
Point being, it's an area of UnixTime that many overlook - to date, since the 1980s I've had long term multichannel data aquisition running throughout every leap second adjustment which would have had data glitches had the time channel been UnixTime, UTC, etc.
Note that UTC has a similar problem - which is why you actually need a local time string for this type of events.
While ISO uses UTC offset and time zone interchangeably it actually is only defined over offsets, not locations.
I've had this problem discussed before. Typically the situation is firing events based on times at specific locations. It is neither straight forward with date libraries nor ist it easy with numeric computation. Sometimes it makes sense to render it down to a specific point in time at storage and not expect the country change timezone overnight. Some times the location itself may be changing randomly (moving objects) but in that case it typically just meant recalculating offsets on movement events.
> Also calculating amount of time between two ISO8601 strings without libraries is nor trivial, or any other operation actually.
That's true of any datetime that actual humans use (as opposed to computers, financial systems, sysadmins and programmers).
That is a weird edge case. I've had this before and the person proposing it hinged on some forensic practice which was based on analyzing human readable data. As I said in my original post, pretty printing ints to ISO timestamps is actually my original opinion.
ISO8601 and friends are literally for formatting dates for the purpose of exchange.
So what? That's true of all formats. How is it relevant to the choice of which format to use at which stage of the process?
> and you have to know what timezone it's in.
You don't.
> clearly a timestamp
Not very helpful. It's easy to set up types in advance. Don't figure out if things look like timestamps at parse time, or you'll be causing the same problems that turn gene names into dates and choke on people named Null.
I don't think there's any case for storing local time with past events. They happened at a specific date and time, store them in UTC and if needed convert to local on display. Plus, though it's a rare circumstance, for one hour each year DST switches cause a duplicate hour - so local time is ambiguous during that hour.
>>> utc1 = datetime.timezone.utc
>>> utc2 = zoneinfo.ZoneInfo("UTC")
>>> utc1 == utc2
False
>>> dt1 = datetime.datetime.now(utc1)
>>> dt2 = datetime.datetime.now(utc2)
>>> dt1.tzinfo == dt2.tzinfo
FalseIf you're working in a system where all dates are utc, then datetime.now() gets you a date in utc and you don't need datetime.utcnow(). The only reason to call utcnow is if you're working on a system where the local timezone isn't utc, so you inherently have to deal with timezones at some level. Which means that using naive timestamps is a bad idea.
If that's messy, consider Nepal's timezone that's on the 45-minute mark (UTC+5:45).
https://en.wikipedia.org/wiki/Chatham_Islands
Right now is it on +13:45 due to Daylight Saving
There isn't a perfect geographical width for time zones. So humans pick something to define the boundaries between time zones. And making boundaries on a map is political.
Way back when, the drive in people won out.
Indiana's Daylight Time mistakes were fascinating. It wasn't that the state didn't adopt it, it was that originally the state allowed it to be a per-county decision as timezones have always been in Indiana. At one point in time if you were traveling I-65 which is nearly due north/south between Louisville and Indianapolis you could experience four different timezones (CST, EST, CDT, and EDT) and which ones agreed with each other obviously depended on which month you were traveling. Since Indiana went state-wide Daylight Time and Indianapolis decided on EDT once and for all, all of I-65 today is EDT I believe, but it is still strange to remember the years where that wasn't the case.
(ETA: one of the underappreciated homogenizing factors here has been the modern cellphone. People would get really confused if their cellphones hopped an hour back/forth every so many miles as you passed county lines. In the eras of paper maps and hand-set clock radios in cars that would have mattered a lot less.)
long time ago there was a special `$ man date` -like page in linux which went into long explaining many "amazing" things about calendar stuff, like whoever feudal in 1553 deciding that certain week was bad and striked it out of his and his country's calendar, or another one that liked certain month and decided to repeat it...
but cannot find it anymore.
Railways are extremely sensitive to exact time and, indeed, the very concept of unified time across the entire region or country only started developing when railways expanded across Europe. Prior to that, individual towns were happy with their own local solar time, but once railway connections were introduced, time irregularities would cause chaos at best and carnage at worst. That led to introduction of unified railway time which developed to timezones as we know them.
Railways aren't as prominent nowadays as they were 100-150 years ago, and countries like Nepal and India don't have extensive, frequently used cross-border railways anyway; any cross-border traffic is sporadic and mostly freight. So there is one fewer reason to cooperate with your neighbors when it comes to time-related issues. Trucks can take weird timezone changes just fine.
Now that the original cause is gone, maybe we can get some new concept going. Timezones seen more terrible than they're worth to me.
I make sure to test with Nepal time whenever I'm testing date/time stuff now.
>>> datetime(1972,1,1,tzinfo=ZoneInfo('Africa/Monrovia')).isoformat()
'1972-01-01T00:00:00-00:44:30'
[0]: https://en.wikipedia.org/wiki/Time_in_Liberia#History> Article unique. — L'heure légale en France et en Algérie est l'heure, temps moyen de Paris, retardée de neuf minutes vingt et une secondes.
The decree which finally replaced it was made on August 9, 1978, and published on August 19, 1978 [1]:
> Art. 2. — Sur l'ensemble du territoire de la République française, le temps légal (ou heure légale) est défini à partir du temps universel coordonné (UTC) établi par le bureau international de l'heure.
[0] https://gallica.bnf.fr/ark:/12148/bpt6k2022333z/f2.item
[1] https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000000880128
Obviously it worked fine, as did Chatham Island.
Yes, you can store additional information to decipher the meaning of a UTC time but why? Storing locale is good because sometimes you need to know where something is, such as when converting the local time to another zone. But you should avoid creating dependencies between these values because it makes using them individually harder.
The coffee shop opens at 6am. That is an unambiguous fact. The coffee shop is in Seattle, WA. That is another unambiguous fact.
If the time is in UTC then you need to know the date the time was set or store a dtc flag and then build some logic to convert. You can just feed local time+locale into any datetime library and get whatever you need.
UTC is great for a lot of things. Such as recording when something happened. But local time has a place as well.
The key here is that the timezone info includes the daylight/standard designation. Or, in the ISO format -4:00 or -5:00 from UTC.
I think you meant to put ET (Eastern Time), which is still 9:30AM, but without a date associated with that time, there's no way to convert that to UTC or other timezones that don't have the same daylight saving time schedule.
So, when possible, it's best to store (future) human events in a localized datetime string. For things like physical events, the opposite is true of course - you can't say what will be the local date and time when the Sun will hit high noon over Athens 10 years from now, but you can certainly calculate the UTC timestamp for that.
Here, I'm not even sure what your point is. A datetime object cannot capture a range, no, just like a number can't capture a range of values. But through the magic of having two of them, we can get easily create a data structure containing two datetimes to represent a range. 5pm is not a vague concept, it is the time 5pm, the hour that typically comes after 4pm and before 6pm. If your point is that you can't store only a time in a datetime object, that's true, that's why the standard library also provides the `time` object which represents a time.
Where things might get a bit more complex is if you want to store the time of a recurring event that should occur at the same time on multiple days for a given timezone. In this situation, you can typically use a naive time object to represent a wall clock time, plus the timezone that the user has requested. This way you still have all the raw information to decide when the event will happen in the future. (Note however, that the same time can occur multiple times on the same day, for example during daylight savings changes.)
And you're totally right about `time` existing, it slipped my mind that time has a tzinfo slot. I do think you should still take care and I would avoid having any naive time objects just floating around beyond the serialization layer though.
You get to have the typing help you enforce that everything is in UTC.
As in, 02:00+00:00 and 04:00+02:00 are absolutely equivalent representations of the same data.
If you need to know the timezone in which to display a time, you save that timezone separately
This is a bit like asking "how do you represent a string length in utf-8?" The answer is, you don’t. It’s almost never a problem in practice.
Just like there is almost never a reason to care about the number of characters in a string, it’s very difficult to imagine that this code comes up in practice. But if it did, the code is simple: for a given timezone, is the current time in utc past 9:30am? If so, the store is open.
If computers do need to know, then they’ll need to know a specific store with a physical location. That gives you the time zone.
Mapping a location to a time zone seems fraught with peril. I’d store the local time zone explicitly.
Another good example. Arizona doesn't follow Daylight Savings, but the Navajo Nation, which includes the Four Corners area and is in three states, does observe the change.
However the Hopi reservation, completely surrounded by Navajo territory, is entirely in Arizona, and does not observe DST. So it can get quite complicated and it's not enough to say "Arizona doesn't have Daylight Savings Time".
You've never wanted to call a business in another timezone before making the trip out there?
However, if I look up the opening time of a Home Depot in another time zone, I expect the result to be in that store's local time! I'll do the conversion myself. If I get my local time instead, I'll still perform the conversion, and get the wrong result.
You could just decide that any time listed anywhere on the internet should include a timezone... but that would be nuts.
I'm trying to poke holes in the "always use UTC and you're good" advice. I have actually encountered this scenario, and I didn't know how to apply that advice.
open | close | store 6am | 6am | default 7am | 12pm | store1
table stores: name | address store1 | xyx NYC
If you can't find the store in the timetable:
1. Get the timezone of the target store by looking up the address from the table stores
2. Set Hours from the default row in the timetable table on the object with the timezone
There's a much simpler one - recurring meetings/events (in-person or local-ish like within one country) that cross a DST boundary. You always want these to be attached to a local time zone, so it doesn't suddenly happen an hour earlier/later than you intended.
Each store will have an opening time, each will store the local time that the store opens.. just as utc.
"9:30am local time" may be ambiguous/unknown (the rules may not exist yet)
Using the same programming type for both may cause confusion.
How do you express geographic coordinates? Noon in London and in NY are different moments in time (it may be important if you want to have a remote meeting).
Your suggestion to define places by their timezone name is ok (it may work in many cases).
Like California is -8 in Standard, -7 in Daylight, so a 9:30 AM opening in the Winter is at 17:30 UTC, in the Summer, 16:30 UTC.
It's a hassle but programmers are supposed to model reality.
As an example of the problems that can arise, I remember when the new Japanese Emperor was to take office upon his father's abdication, there was a big fuss because the Era Name was customarily only revealed after the new Emperor's reign started but all the computer people wanted to be ready in advance. Not sure what finally happened, if it was revealed in advance or not.
UTC to local time is not a function, it is not somethung that can be computed once and stored for the future. The two are fundamentally different concepts, and can only be related to one another in certain contexts, and only reliably for the past.
There are a number of libraries for this, usually updated by the unpaid volunteer in Nebraska. Or else your company has staff whose job it is to follow this for any place you operate.
If you record opening times as UTC, well, then you have to change to UTC when the store switches standard <=> daylight.
This is what Fred Brooks called an essential complexity. You can poke the pain from one part of your system to another part, but it's never going away.
The function is complicated. There is no avoiding that.
One Pacific island nation duplicated a calendar day when it switched International Dateline sides to more closely align with Australia instead of Hawaii, reflecting a shift in its economic ties. No idea how they handled it exactly but pretty hairy to model.
It’s not a date time.
Reminds me of when Numpy removed a lot of types like np.bool a few releases ago, because they were aliases of the standard library types.
Which broke a ton of libraries having Numpy versions pinned to ">=1.0" or even worse, "~=1.0" expecting them to follow the standard practice of incrementing the major version when they break compatibility. It's not terrible because you just pin your project to 1.23 or whatever, but it was very annoying when everything I was using just started breaking.
I wonder if Python plans to do the same with this - the 2 to 3 transition was painful and dragged on for a decade, nobody wants to do that again for 3 to 4. When they remove this function and break back compatibility with old code, is that going to happen in a future 3.x release?
https://numpy.org/neps/nep-0023-backwards-compatibility.html
https://numpy.org/doc/stable/dev/depending_on_numpy.html#run...
So, when using numpy in a package, and you've tested e.g. versions 1.12 to 1.22, you should require 'numpy>=1.12,<1.25', because something deprecated in version 1.23 could be removed in 1.25.
I think in some senses these backward compatibility breaks have already happened. I remember that Google got bit by async becoming a keyword in I think Tensorflow.
Generally a lot of old Python 3 code still works today if it doesn't do anything really weird like that, but I do definitely think that the pain of Python 2 to 3 was painful so they don't really want to repeat it.
I think it is probably prudent to treat point releases as major releases at least with regards to Python.
You have to store time in the relevant geographic time zone. Something occurring at 1200UTC on dec 1st is not the same as something occurring at 1200Europe/London on dec 1st. The two times may coincide today, but if the U.K. government decides to implement daylight saving next week as a fuel rationing measure, then your 1200London event will have to be displayed at 1300UTC, but your 1200UTC event would be at 1200UTC.
Point remains, many events are linked to local civil time, which can change - and not just to daylight saving. The Line Islands in Kiribati shifted a whole day in 1994, same with Samoa in 2011. Have an event set for 0800 local on the first Monday of the year in Samoa which you stored as UTC, and your events would have broken. Unless you store the relevant data (it occurs on first monday according to the timezone that Samoa is in), then you will be wrong.
Now of course you can still get problems if a new timezone is created, as time is stored as Europe/London, if Scotland creates its own timezone in the future a meeting in Aberdeen would no longer be in Europe/London but in a new area Europe/Edinburgh, with different behaviour, but that’s far less common than DST changes or other date shifts.
All in all you should store the relevant datetime and zone, not just “normalise” it to UTC.
Which is scary, because you will be taking the performance hit from generating the warning regardless, which can easily amount to 30% of your total CPU time if you use utcnow/utcfromtimestamp a lot.
datetime.datetime’s utcnow() and utcfromtimestamp() are deprecated and will be removed in a future version.I seem to remember reading that remove-if-not is deprecated in Common Lisp, and that this is almost universally viewed as a mistake, but it remains deprecated (and the deprecation is ignored by everyone) just because the standard doesn't change anymore.
(It's going to break from the eventual removal)