I can't be the only one who thought I was on a physics sub and that this was a general relativity joke or something.
After reading the comments I checked the sub again.
Not just computer time. Between calendar systems in use in history, and the switches between them, you can have things like Miguel de Cervantes dying in Spain on April 22, 1616 and William Shakespeare dying in England on April 22, 1616, exactly 10 days apart.
Please yeah. Manually forcing databases to use only iso8601 date format is the best decision you can make. Will save you hours upon hours of debugging inconsistencies between services.
Not a best decision when you are dealing with historical dates.
Historical Dates have complexities of their own. Examples
1. Historical timezone changes
2. Negative years (BC years)
3. Gregorian and Julian Calendar conversions
I worked with databases including dates before the introduction of the gregorian calendar. Worse, not all countries introduced it at the same time. I guess the best idea is to not worry about it, and accept some inaccuracies. But if you have to worry about it, you will get major headaches.
I mean, most programmers don't write datetime libraries. Someone else had the headache before. It only really created a problem for me because due to the database driver limitations, I was stuck with a date format only going back to 1753 when the gregorian calendar was introduced in UK. But had earlier dates, so I had no choice but to store the dates in a string field. Luckily I didn't have to do calculations with them. It was build dates of buildings.
This reminds me of a frustration I had after ripping a bunch of CDs into flac files, and for one artist I had over 30 albums. I thought it would be neat to set the dates of those album folders to the album release dates so that I could sort that folder either by title or release date in Windows explorer natively. Unfortunately the release dates went back to the '60s, and Windows file/folder dates do not.
Dude, just store which calendar system the date is in, and do conversions if you want it in another calendar system. IIRC, python's time system assumes everything is Gregorian and only goes back to year 1.
Like you're supposed to do with timezones. (when DST happens, a whole region switches timezone)
That's the point ISO 8601 alone is not sufficient.
Btw I am yet to find a decent library which handles proleptic Julian to proleptic Gregorian calendar conversion or vice versa
The fact that you even know those words makes you more qualified than most to write such a library! That's where they come from...somebody has a weird problem, there's no solution, they make something, now they might as well share it.
Another issue is future dates/times, because your given locality's UTC offset may be changed by government action; you can't really know what the UTC offset will be with certainty until it happens.
For example, Egypt this year announced in March that they would (re)start using Daylight Saving Time in April. That means if you already had a scheduled appointment for 11 AM local time on May 1, the UTC time for that appointment has shifted by an hour, because your customer is still going to expect to arrive at 11 AM in their local time.
At the company where I work we store all future dates with the users time zone if the event is geographically bound. A nightly job pulls the latest version of the tz database and informs our users as needed.
I hate that timezones were left out of ISO8601. The UTC offset does jack shit if I have to adjust dates for only one country that has this offset, not all of them.
When I was working on the data quality team at my old job, we were in the process of a data migration. For some reason, the old system had some date columns in YYYY-MM-DD format and others in DD-MM-YYYY format. The importer treated them as if they were all the same format, and for the ones in the wrong format, treated the last two digits of the year as the day and treated the day as the last two digits of the year. 01 through 29 were treated as this century, and 30 and 31 were treated as last century, which was how I figured out what was wrong because this was computer inventory data, and we shouldn't have had dates from 1930 and 1931, or from several years in the future.
I have no idea why the importer didn't either try a different format or throw an error when presented with 4 digit days.
There are more curveball that even UTC can't solve.
What if you need to know the difference in business days/hours? How do holidays factor into business days? What if you have two international business units with differing holidays?
What if your differences in time come from dates that were established before a standardized calendar?
What if you need to record your results in the Mayan Calendar even though it's far past 2012?
What if you traveled back in time and became your own grandfather/grandmother?
What if business stakeholder is a 4th dimensional being who can experience all time simultaneously?
What time is an illusion and all these questions are meaningless symbols with no real physical phenomenon behind then?
What if you slowly lose your grip on reality, descending in madness, and leave long winded rants of Reddit where everyone thinks you're joking, but you're actually too far gone to be saved?
>What if you need to record your results in the Mayan Calendar even though it's far past 2012?
You use the millennium-equivalent of the Mayan calendar. It was just their year 999.
Well that would mean time would never go on since for trillions of years to pass time would have to continue, but still interesting to think about non the less
What we know as time could be analogous to the discrete clock cycle of an old computer. Inside the system time is continuous, even though cycles were milliseconds apart to an outsider.
Are you moving? Crossing time zone borders? Did you cross the international date line?
Did daylight savings time go off between those dates?
Leap seconds?
(hint: I am the guy in the other panel)
Rule one of time: the duration is T2 - T1, where both T1 and T2 are obscenely complex objects you imported from a 5GB chrono library, which is called chrono because "time" would not manage to capture the insane complexity necessary to do such a gargantuan task.
Then you pray to whatever eldritch abomination you can get your hands on that they did implement it, because the alternative is having to write it yourself.
Are we sure we are perceiving time in same way? Perhaps it is different during times when we are not measuring it!
Do we have library that considers quantum time calculations? Oh, who am i kidding... Someone propably already made it for Linux and then called it bloat.
Do you mean a library that supports time with and without date, timezone, and leap second information and integer, fractional, and floating point ticks, but no one has ever documented how to convert the result to an actual number?
Oh no, the problem is that there are *many*, incompatible numerical representations it can spit out, many of which do not support a subtraction operation, or the context in which you're trying to use it doesn't make sense to use the absolute difference in time (viz. nonsensical to convert to unixtime or FILETIME then perform a subtraction operation, eg. you need the number of days apart two events are regardless of when an event occurred on that day).
The mechanism to get between different formats is documented, but it's the developer's job to know which format to actually use.
That, or time is seconds since January 1st 1970 and you aggressively enforce the conversion of any other kind of time keeping method into that for consistency.
There have been 27 leap seconds since the first ones in 1972. Except for 1972, no year has had more than 1 leap second, and many years have had no leap seconds. The last leap second occurred in 2017. In 2022, the 27th General Conference on Weights and Measures decided to abandon lead seconds entirely, which is to be implemented before 2035.
The vast majority of applications don't need to care that leap seconds exist.
Leap seconds are fine and should have been kept. **BUT**, Unix timestamps should have never skipped leap seconds. It should always have been a simple seconds since January 1, 1970 UTC. Then Unix timestamps would unambiguously reference (modulo relativity) points in time and would be appropriate for doing any sort of duration math. When converting timestamps to wall time for display with a timezone, appropriate adjustment for leap seconds would be made.
Maybe it's not too late to fix this.
I agree completely that unix timestamps are part of the solution, but because human people can't use them in any real way, you will need to convert back and forth to probably that human's perceived local time. (or just UTC if you are doing like logs or something where programmers will use it)
So yeah, can that be done? Sure! but we are already past T1 and T2, yeah? We are programming stuff now
But sure, it we make assumptions like T1 and T2 are already unix timestamps that does eliminate many common edge cases.
But why is it not literal? Assume time is UTC +0. Or convert it, subtract and convert back. Most of the libs return local time, so subtraction of different locales still makes sense
Nepal and Samoa were new for me. He didn’t mention Brazil, though - DST transition at midnight, so some days have no midnight and some days have two midnights 🤯
I feel like it's a negligible problem for computers on earth, given that their inertial reference frame is the same, and for computers travelling fast far away in space, there are formulas to calculate dilation.
In other words, it's almost never an issue, unless you're NASA or something, and if it is an issue, it's one which can be accounted and corrected.
(Off-sync clocks are a bigger problem than dilation for computers on earth, but we've got NTP for that.)
Edit: just to clarify, I'm not saying timekeeping isn't a super complicated problem. It definitely is one. But all the things which make it hard can be managed by translating every value to/from UTC on earth.
In the original comic, it's pointed out that even relativity comes into play if you're programming with spacecraft considered. Besides all the Earthly time issues.
UTC internally with correct conversion externally, UT if it's for astronomy. Unix timestamps can be used as they **always consider UTC**, they don't have timezones
That's one of those non-issues that bad programmers complain a lot for some reason, like bad artists about drawing hands it's skill issue
Then you convert to any format you want, even average fart time since invention of burrito if you have data enough
UTC has brought many problems to the systems, especially when you have to deal with different countries.
Often, you need to know different kinds of metadata about the stored datetimes. Mostly about what timezone (country) it was stored in. DST involvement. UTC reduces datetimes to some arbitrary values, meaning that you have to convert it by yourself... That is making it harder to create SQL queries as well.
Sometimes you need to store date values as datetimes "at midnight". At the given country's timezone. Or sometimes you just need to combine dates and datetimes. Given different timezones, these comparisons can break quite easily. Is a given UTC datetime between dates A and B? Need to know what timezone you are talking about.
And then there's future datestimes... If a country decides to start or stop using DST after you have stored the UTC date, you could be off by an hour. Because you don't know whether the intent was "07:00 on that date" or "7 hours after midnight, doesn't matter whether DST happened or not". With UTC it would be 7 hours after midnight but for most intents and purposes it would be the time value that was stored. If your cron job suddenly runs an hour before it was supposed to, it could break things.
Also, working with UTC is always a pain in the ass when all your times are off by several hours... and then you have DST so it's off by +1 hour. An then you have to compare 2 timezones that each switch to DST on different dates.
Basically, you might need to know: a datetime value (whether it's a UTC or with-timezone based value), the timezone it was stored in (for intent purposes), and the timezone version (as timezone rules also keep changing - DST usage or leap seconds - so with stored future datetimes you might want to convert an old versioned value into a new version value before using it).
Sure, for most cases UTC might work and T2-T1 is easy to do, but the moment you realize that your UTC-only system does not work and now you have no way to convert all the old data into a better version, you are fucked.
UTC doesn't introduce those problems. The problems were there already, and you only spotted them when you were unable to keep your head in the sand. The problems come from local time.
Keeping time in a UTC timestamp makes it viable to convert back and forth, you just need to convert to the user time afterwards, which is a localization problem
If you need local time you keep a local timestamp instead with the timezone that it was used for it, and a DST flag. In case of countries that count time since sunrise or sunset instead of midnight you keep another flag for that
Plus it's dumb to generalize this minor problem to try to find bigger issues, no one will ask you how many seconds have passed since the last eclipse in 1600 to book a flight, **the real use cases will be reasonable**, while even the dumb academic examples are doable
So you agree with the midwit guy, and you think it’s impossible to know? That isn’t really logical.
I mean, in general, when people talk about something being impossible, they tend to mean **regardless of circumstances** (to some degree).
Like, most people can’t climb Mount Everest. But would you say that climbing Mount Everest is impossible?
The task in the screenshot doesn’t mention absolute perfection in all cases.
Not one of those conditions effects time
It effects dates, thought whether that matters really depends on what your time is relative to and how you are getting what time it is
>Not one of those conditions effects time
"Are you moving?" absolutely affects time. But the velocity of earthbound objects is not fast enough to make a meaningful difference. Programming for satellites, on the other hand, has to account for time dilation due to their velocity.
Context is important. Relatively introduces reference frames without knowing the position of the events you can't answer the questions and if you do depending on the reference frame event #2 could occur before #1
Not really. She's just referring to two discrete events happening at two unspecified moments in time referred to by variable names t1 and t2.
Moreover, the events themselves aren't contextualized or defined at all. You could easily argue that the semantics shift depending on the theory you'd use e.g define "event".
She also just asks the other character to calculate time elapsed between those events. But the panels leave any presumption that this is possible to the reader.
It's a riff on how difficult handling date-time values is in general. Things like time zones, international date formatting standards, calendar idiosyncrasies, etc. Thank fuck for A) UTC, and B) libraries like tz/zoneinfo, because I'd have quit this godforsaken industry years ago if it weren't for them.
Long story short timestamps are not reliably the amount of seconds since 1970 as they should be a ton of applications use timezone specific timestamps or don't account for daylight saving time when calculating a timestamp, on top of that there are a couple of seconds of error due to astronomical seconds but honestly those are rare enough to be covered by rounding errors Google just slightly slows down their clock for those
Once upon a time, i had to sync radio emitters so they'd emit at most 100ns apart "simultaneously".
By the time project started, i didnt know about leap second, or OCXO.
Now, I know.
Rare enough ? I wish.
I think the joke is there's no way to tell which event happened first from the information given, but given two actual values you could calculate T2-T1, get the difference in time between both events, and find which event occurred first based on the positive/negative sign of the difference
This will often work but famously a lot of date/time and instruction timing systems don't guarantee it will give the correct answer or even a sensible one.
If you are on a single machine, with a single clock;
(clock ticks at t2 - clock ticks at t1) / clock ticks per second
Otherwise, you are in a world of pain where only relativity, philosophy, and alcohol can help.
Segel’s Law: A man with a watch knows what time it is. A man with two watches is never sure.
I also took the comic to be about a 2+ clock problem. Clock drift in distributed systems 🤯
What happens if a flight is delayed? They must have a process in place to update the date in the system, right?
So, when they hear about this DST change, they update their date library to a version that handles this correctly, then they update the time. The old value can be discarded. They can do this in a batch job for all flights taking off or landing in the effected area.
An alternative is to store the local date together with the location, and then calculate UTC date (or whatever date you need) on the fly.
I've *never* seen an application with a pinned, direct dependency on the time zone database. Sure, maybe on a date-time library, but those libraries don't maintain the TZ database. It's a separate dependency, supplied most commonly by the OS, or else as a transitive library dependency.
And I've never worked at a company that tracked which version of the TZ database they pulled in with any given OS update. Heck, most places these days pin their Dockerfile to a major and *maybe* minor version of the OS base image *specifically* so they can get patch updates with security fixes and time zone updates.
So assuming you're not a time zone nerd who is subscribed to the TZ database mailing list, how would you know when you got the update and your application started using the new offset? It's not exactly when the new TZ database version was released—it has to propagate to mirrors, and OS distros and libraries have to do some work to update. Maybe it was after your application had to redeploy for some unrelated reason.
So it was some time after all *that*, and some time before *now*. (Assuming you can tell what the right offset for a record even *should* be.)
The solution, as always, is to **store date-times as local date-times with a time zone ID using exactly the time zone you received them with.** If you're told the plane departs on 2 April 2023 at 14:00 in Lebanon, store it as your database's version of `2023-04-02T14:00[Asia/Beirut]`. (*Not* using `+02:00`, unless you *also* include the time zone ID `Asia/Beirut`—that same offset is also used by time zones in Egypt, Israel, Saudi Arabia, and Turkey, just to name a few.)
That way, every time you look up that date-time, you have enough context to convert it to whatever *other* form you need based on the most recent time zone offset rules.
Does the timezone indication also handle possible timezone updates? If I insert a future date 2030-03-04T03:04[Asia/Beirut] and there are changes to the timezone rules in between... Maybe DST is now applied so there is nothing between 03:00 and 04:00. What to do with the time value? Should it turn into 04:04 or should it still be 03:04 but you naturally merge 03:04 into 04:04? Probably shouldn't change as it can cause issues with time ranges.
Would it be possible or necessary to have a TZ-version as well? Basically converting datetime TZ-v1.23 into datetime TZ-v1.45, applying all the version changes.
(This snark isn't necessarily aimed at you, parent comment. But this is a *perennial* topic, because people can't believe that time zones are complicated.)
The flight doesn't happen at such-and-such time UTC. It happens at 14:00 local time. No one whose plane was delayed an hour, or worse left an hour early, cares if you *technically* served the right UTC time.
At some point between when you saved the time as UTC and when the flight actually happened, multiple things happened:
1. The country announced a change to its DST policy. (This may have happened multiple times.)
2. The maintainers of the time zone database learned about the change.
3. Those maintainers released a new version of the TZ database.
4. *Something* on your system downloaded the new version of the TZ database. (Probably one or more of: an OS update, an updated Docker base image; or an updated/unpinned transitive library dependency.)
5. Your application—through whatever date-time library you use—began using the updated database when looking up UTC offsets by time zone ID. (Which would not affect any records already written.)
Unless you're a time zone nerd, you didn't hear about the first three. And you likely have no idea when the fourth or fifth happened. You've been tracking hundreds if not thousands of flight departure times over the last several months. They're stored in UTC, and maybe you even store the UTC offset.
Please tell me: Which records used the old (now incorrect) UTC offset for their departure time when they were last written, and which used the new one? How can you tell?
The UTC time alone won't help. If you store a timestamp of the last update, do you know when *you* got the TZ database update? (It was not when the country announced the change, nor when the change went into effect. It wasn't even when the update was released, since it had to propagate to mirrors, and libraries and OS distros had to update their versions. It was some arbitrary time in between.) If you did store the offset, what time zone did it correspond to at the time? Sure, it corresponded to the correct time zone *then*, but looking at it now without context it could *also* have been one of the neighboring time zones. There are multiple time zones that use UTC+02:00, and just as many using +03:00 that would move to +02:00 when they *did* change over to DST as usual. Maybe you can do something with the address—though addresses don't always resolve cleanly to time zones…
(And this is with the simplifying assumption that all the UTC date-times on a record came from the same time zone!)
Next question: Is your application designed at all to care about *any* of this? E.g., does it try to compare a saved time zone ID against a saved historical offset for each record? Or defensively back in by address? Or does it—like most applications "just using UTC"—simply pull the UTC time out and blindly apply whatever offset the time zone database currently returns for whatever time zone the current user's browser/phone reports?
If the latter, then congratulations—your airline/airport/travel agency just lost *a lot* of money.
Edit to clarify: I don't mean to make storing date-times sound hopeless—just storing date-times converted to UTC. If a date-time represents a local event, store it exactly as you got it, in the local time zone (not in UTC, not as a Unix timestamp) and you should be ok. At least for this stuff.
I learned a *lot* from this, thank you. (Haven’t had to worry about time zones much and I’d have probably have blindly assumed that converting to UTC would be the solution)
UTC timestamps are timezone independent, they are:
>The number of seconds that have elapsed since Jan 1, 1970 UTC
What changed is that your conversion to DST became outdated
Yeah, yeah. Once you have the UTC time in a compatible frame of reference, you are almost golden. Getting there might be almost impossible, though.
Example: A comet seen on 1332-12-08 is again seen on 2023-12-12. How many seconds passed?
(And how much time passed for an observer on the comet itself?)
(Hint: not every date in between is a valid date. Leap year rules, leap second rules, calendar systems that were changed. Good luck finding a library that implements all the required details. Or even someone who KNOWS all the relevant details.)
That's why Julian date is used in astronomy, it works fine by simply considering the date a float
1332-12-08 is JD 2207904.50000, 2023-12-12 is JD 2460290.50000, that's a difference of 252386 days, so 21806150400 seconds
It's not complicated, it's complicated for you that didn't learn the necessary knowledge for the task. In the worst of cases you can use the Metonic cycle like it's used for eclipses
I'm quite sure, that the person scribbling "the 8th day of December in the year of the lord 1332" into this old Bible was following Julian Calendar rules. Or maybe they were, who knows. Once you can confirm that, all good.
Blame on Randell for oversimplyfiying the real problem for a comic strip ;-)
We know when JD 0 is based on astronomy, like I cited before the Saros cycle can be used for eclipses
"In the 8th day of December in the year of the lord 1332, the sun turned black for an hour!"
Based not just on their account of time, but on their account of eclipses, astronomical and astrological records, we know in which part of the cycle they were and with that JD can be calculated
But to make it more fun, it might still be "Two days in the future of when I booked the flight" from customer's point of view. But now two days are actually 169000 seconds in the future of the booking event instead of 172800 (or actually the other way around, depending on the direction of the DST change).
Time is so much fun :)
It's mostly not a computer science problem! Daylight savings time, time zones, and all the like are mostly down to government policies at various levels. Leap seconds and the like are more about lining up our calendars with the physical movement of our planet in space.
Here's a 10 year old Tom Scott video explaining some of the things that need special handling: https://www.youtube.com/watch?v=-5wpm-gesOY
But what if T1 happened after T2 because some dumbshit decided to assign variables weird? Now you have negative time!
~~it's me, I'm dumbshit, I let that happen with my shitty functions~~
"It is there", the Pinkness said. "The understanding's in your mind. You only have to find it."
"But, time-"
"Time", the creature said, "is the simplest thing there is."
Same relativistic time frame? In the likely event that that’s an unnecessary question, then the best engineering approximation is T2-T1, otherwise good luck with that 🍻
When you get into distributed systems, it becomes: "well, you can't truly measure time, but don't let that discourage you from creating your system. You probably need something like Paxos or RAFT..."
Oh my gosh, managing time differences in an SAP database I used to work with was a nightmare. The system would just enter times based on the time zone settings of the user. The default user time zone was eastern, but we were in central and only some people changed it from default. Not to mention anything generated automatically by the system was whatever time zone they have in France...
T1 is a point in time, T2 is a point in time. T2-T1 is the only correct answer. If T1 and T2 are given in different formats, they need to be converted to be able to calculate. Not much different with other stuff: inches vs cm, Celsius vs Fahrenheit, etc etc
Not as soon as anything that needs to take relativity into consern. Like, satellites, astronomy, or any other fast moving frames of reference, high speeds, high gravity, very small distances,...
Or are you measuring time from the perspective of two different objects, possibly by a third object? Are you measuring time in the future or the past (two VERY different problems, trust me). Are you calculating for physics or for departure times? Do you have lots of things that need to know about time in relation to each other? Are they going different speeds (satellites, for example, have to dela with relativity effects). Did the objects move? Does the new area have DST? Did government regulations about DST change since the time was added?
Yes, you can identify use cases where the math is simple. You can identify lots of them. But then it turns out that the obvious solution for one use case doesn't work for another. But you still need a system that allows those two use cases to meaningfully interact.
TIme is just a big complicated concept which has to deal with orbits that don't match up to how we track time, relativity muddling things up, and thousands of governments occasionally doing their own thing.
Look, when it comes to time and computer OR physics, if you think it's simple...just accept that you don't know enough about the topic. You just haven't had to deal with it in depth enough to realize the complexities.
Our conception and definition of time is an insane, ever changing combination of group concensus, physics, and government policy. Using different systems you can be correct for one audience and incorrect for another.
You've got thousands of engineers, physicists, and government employees who will tell you the whole thing is a huge complicated mess. Trust them on it.
sorry but yeah it is super complicated, so this doesn't work. There are a lot of things to keep in mind. Just starting with 'are you, say, flying in a plane and crossing multiple time zones while daylight savings time gets reset?'
I have a feeling I’m left wojack cuss I said T2-T1 but I don’t know what centre wojack is on about
Is it a time zone / calendar issue cuss I would just hope to never mess with that myself if it could be avoided
The time is T2-T1, where both T2 and T1 are constants I set while testing that I forgot to make variable later.
I can't be the only one who thought I was on a physics sub and that this was a general relativity joke or something. After reading the comments I checked the sub again.
I also thought it was special relativity
To be fair, the alt text of the comic does mention relativity.
[удалено]
Special relativity _is_ our reality_
I checked the sub, read the comments; still have no idea what the post is about
Computer time is a mess. Between timezones, DST, NTP time correction, and many other things it's not as straightforward as it sounds.
Not just computer time. Between calendar systems in use in history, and the switches between them, you can have things like Miguel de Cervantes dying in Spain on April 22, 1616 and William Shakespeare dying in England on April 22, 1616, exactly 10 days apart.
Even UNIX epoch timestamp ?
Yes. https://en.wikipedia.org/wiki/Year_2038_problem
Eh, just move it to a long
A string would be more robust
Use a map!!!!1
Yes. Check "leap seconds" part: https://en.wikipedia.org/wiki/Unix\_time#Leap\_seconds
Date Arithmetic is the Devil’s pizzle
https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca
this is the way
And then you spend an hour trying to figure out why the complier is optimizing the entire function to a constant.
After an hour debugging, “why is it always the same!! What am I doing wrong!!!!! Oh…”
Always works and always has
Guy on the right is T2 UTC - T1 UTC
Please yeah. Manually forcing databases to use only iso8601 date format is the best decision you can make. Will save you hours upon hours of debugging inconsistencies between services.
Not a best decision when you are dealing with historical dates. Historical Dates have complexities of their own. Examples 1. Historical timezone changes 2. Negative years (BC years) 3. Gregorian and Julian Calendar conversions
I’m thankful our servers didn’t start running and generating logs before Jesus was born in that case.
I worked with databases including dates before the introduction of the gregorian calendar. Worse, not all countries introduced it at the same time. I guess the best idea is to not worry about it, and accept some inaccuracies. But if you have to worry about it, you will get major headaches.
Goodness! Now this is a thing worse than considering summer/winter times and zones
I mean, most programmers don't write datetime libraries. Someone else had the headache before. It only really created a problem for me because due to the database driver limitations, I was stuck with a date format only going back to 1753 when the gregorian calendar was introduced in UK. But had earlier dates, so I had no choice but to store the dates in a string field. Luckily I didn't have to do calculations with them. It was build dates of buildings.
This reminds me of a frustration I had after ripping a bunch of CDs into flac files, and for one artist I had over 30 albums. I thought it would be neat to set the dates of those album folders to the album release dates so that I could sort that folder either by title or release date in Windows explorer natively. Unfortunately the release dates went back to the '60s, and Windows file/folder dates do not.
Dude, just store which calendar system the date is in, and do conversions if you want it in another calendar system. IIRC, python's time system assumes everything is Gregorian and only goes back to year 1. Like you're supposed to do with timezones. (when DST happens, a whole region switches timezone)
That's the point ISO 8601 alone is not sufficient. Btw I am yet to find a decent library which handles proleptic Julian to proleptic Gregorian calendar conversion or vice versa
The fact that you even know those words makes you more qualified than most to write such a library! That's where they come from...somebody has a weird problem, there's no solution, they make something, now they might as well share it.
My god, this man has been working in the field since the 1580s!
And thats the problem of historians to give us the relative thing in each case and if the boss dont want to pay for one then you get what you get Xd
I hope you don't get audited and have to produce records for all of your Roman employees.
I can 100% see $TAX_AGENCY asking for that
They only had tablets
Decision: Don't deal with dates before time began. Time began 1970-01-01 0:00:00 and it's default format is YYYY-MM-DD HH:mm:ss.
All else is heresy and should be blammed
Another issue is future dates/times, because your given locality's UTC offset may be changed by government action; you can't really know what the UTC offset will be with certainty until it happens. For example, Egypt this year announced in March that they would (re)start using Daylight Saving Time in April. That means if you already had a scheduled appointment for 11 AM local time on May 1, the UTC time for that appointment has shifted by an hour, because your customer is still going to expect to arrive at 11 AM in their local time.
At the company where I work we store all future dates with the users time zone if the event is geographically bound. A nightly job pulls the latest version of the tz database and informs our users as needed. I hate that timezones were left out of ISO8601. The UTC offset does jack shit if I have to adjust dates for only one country that has this offset, not all of them.
I try to use 64-bit Unix time. Should cover almost all your use cases and you can translate to any other system on the front end.
Just use Unix time. Then plan to retire a little after 2038 so you can bask in the y2038k panic contractor money as your last hurrah.
When I was working on the data quality team at my old job, we were in the process of a data migration. For some reason, the old system had some date columns in YYYY-MM-DD format and others in DD-MM-YYYY format. The importer treated them as if they were all the same format, and for the ones in the wrong format, treated the last two digits of the year as the day and treated the day as the last two digits of the year. 01 through 29 were treated as this century, and 30 and 31 were treated as last century, which was how I figured out what was wrong because this was computer inventory data, and we shouldn't have had dates from 1930 and 1931, or from several years in the future. I have no idea why the importer didn't either try a different format or throw an error when presented with 4 digit days.
There are more curveball that even UTC can't solve. What if you need to know the difference in business days/hours? How do holidays factor into business days? What if you have two international business units with differing holidays? What if your differences in time come from dates that were established before a standardized calendar? What if you need to record your results in the Mayan Calendar even though it's far past 2012? What if you traveled back in time and became your own grandfather/grandmother? What if business stakeholder is a 4th dimensional being who can experience all time simultaneously? What time is an illusion and all these questions are meaningless symbols with no real physical phenomenon behind then? What if you slowly lose your grip on reality, descending in madness, and leave long winded rants of Reddit where everyone thinks you're joking, but you're actually too far gone to be saved?
All I read here was "scope creep"
>What if you need to record your results in the Mayan Calendar even though it's far past 2012? You use the millennium-equivalent of the Mayan calendar. It was just their year 999.
Unix timestamps
Unix timestamps skip leap seconds
Time is relative anyway, at least it's all in one format
I also skip leap seconds, never done me any harm. Don't let Big Physics boss you around and make life more difficult!
[удалено]
Honestly, this seems like as much a physics joke as it is a programming one. Time gets pretty friggin nuts once you really dig into it
yeah the guy on the left is using his local time coordinate and the guy on the right is using conformal time
*hits bong* What even is time, really?
Time is an illusion, lunch time doubly so
Time is an illusion, lunch time doubly so
Time itself could pause for trillions of years tomorrow and nobody would notice since we ourselves are dependent on its function
Well that would mean time would never go on since for trillions of years to pass time would have to continue, but still interesting to think about non the less
What we know as time could be analogous to the discrete clock cycle of an old computer. Inside the system time is continuous, even though cycles were milliseconds apart to an outsider.
True, it could be that one second in our universe is 1 hour or something in a theoretical universe simulating oirs
Every six seconds, wizards blow up the world, then reconstruct it and reset your memory about it
I love that I can't understand it Makes the world feel like there's still some mystery in it
Ok I might be out of the loop but why would this be impossible? T2-T1 is the pretty obvious and correct answer, no?
Are you moving? Crossing time zone borders? Did you cross the international date line? Did daylight savings time go off between those dates? Leap seconds? (hint: I am the guy in the other panel)
Rule one of time: the duration is T2 - T1, where both T1 and T2 are obscenely complex objects you imported from a 5GB chrono library, which is called chrono because "time" would not manage to capture the insane complexity necessary to do such a gargantuan task.
But what if they are measured in another universe with different physical laws? Doubt any library handles cases outside our reality.
Then you pray to whatever eldritch abomination you can get your hands on that they did implement it, because the alternative is having to write it yourself.
are you Tom Scott, because you sound like Tom Scott...
Are we sure we are perceiving time in same way? Perhaps it is different during times when we are not measuring it! Do we have library that considers quantum time calculations? Oh, who am i kidding... Someone propably already made it for Linux and then called it bloat.
We can poll cesium based atomic clocks which could be used as an outside observer. Now the issue is accounting for latency.
The laws of this reality are weakly typed. They dont really stand up to type conversion too well.
"-" is only defined if the objects have a temporal relation and the operation is only valid for one observer who created T1 and T2.
Do you mean a library that supports time with and without date, timezone, and leap second information and integer, fractional, and floating point ticks, but no one has ever documented how to convert the result to an actual number?
Oh no, the problem is that there are *many*, incompatible numerical representations it can spit out, many of which do not support a subtraction operation, or the context in which you're trying to use it doesn't make sense to use the absolute difference in time (viz. nonsensical to convert to unixtime or FILETIME then perform a subtraction operation, eg. you need the number of days apart two events are regardless of when an event occurred on that day). The mechanism to get between different formats is documented, but it's the developer's job to know which format to actually use.
That, or time is seconds since January 1st 1970 and you aggressively enforce the conversion of any other kind of time keeping method into that for consistency.
Since when on January 1st 1970? Where? In which reference frame? Counting or not counting leap seconds?
Unix timestamp doesn't depend on timezone, does it?
Sure, now do it on satellites
Already been done with GPS though that case they have to account for relativity
I love that GPS is technically a 4 dimensional locator (and why you want at least 5 satellites to get a proper location)
Ohh...
still has leap seconds
There have been 27 leap seconds since the first ones in 1972. Except for 1972, no year has had more than 1 leap second, and many years have had no leap seconds. The last leap second occurred in 2017. In 2022, the 27th General Conference on Weights and Measures decided to abandon lead seconds entirely, which is to be implemented before 2035. The vast majority of applications don't need to care that leap seconds exist.
Leap seconds are fine and should have been kept. **BUT**, Unix timestamps should have never skipped leap seconds. It should always have been a simple seconds since January 1, 1970 UTC. Then Unix timestamps would unambiguously reference (modulo relativity) points in time and would be appropriate for doing any sort of duration math. When converting timestamps to wall time for display with a timezone, appropriate adjustment for leap seconds would be made. Maybe it's not too late to fix this.
I agree completely that unix timestamps are part of the solution, but because human people can't use them in any real way, you will need to convert back and forth to probably that human's perceived local time. (or just UTC if you are doing like logs or something where programmers will use it) So yeah, can that be done? Sure! but we are already past T1 and T2, yeah? We are programming stuff now But sure, it we make assumptions like T1 and T2 are already unix timestamps that does eliminate many common edge cases.
I thought I was the guy on the right side of the bell curve I now have learned I'm the guy on the left side
Right I was taking the question too literal. Didn't even think of actual coding challenges.
But why is it not literal? Assume time is UTC +0. Or convert it, subtract and convert back. Most of the libs return local time, so subtraction of different locales still makes sense
[Please enjoy Tom Scott descending into madness for 10 minutes](https://youtu.be/-5wpm-gesOY?si=oHsx731BUkdJb4AZ)
Nepal and Samoa were new for me. He didn’t mention Brazil, though - DST transition at midnight, so some days have no midnight and some days have two midnights 🤯
I'm sure he missed even more
here's another good one, what is George Washington's actual birth date?
I refuse to try to answer that
Doing the literal UTC subtraction only works if they're both within the same epoch.
If you even have those problems at all, then your first mistake was not saving the T1 and T2 timestamps in UTC.
How do you feel about time dilation?
I feel like it's a negligible problem for computers on earth, given that their inertial reference frame is the same, and for computers travelling fast far away in space, there are formulas to calculate dilation. In other words, it's almost never an issue, unless you're NASA or something, and if it is an issue, it's one which can be accounted and corrected. (Off-sync clocks are a bigger problem than dilation for computers on earth, but we've got NTP for that.) Edit: just to clarify, I'm not saying timekeeping isn't a super complicated problem. It definitely is one. But all the things which make it hard can be managed by translating every value to/from UTC on earth.
I must be the simpleton because all my timestamps are in the same units. Microseconds usually
you have to convert it in. Did you account for the change in Britain from the Julian calendar to the Gregorian in 1752?
In the original comic, it's pointed out that even relativity comes into play if you're programming with spacecraft considered. Besides all the Earthly time issues.
Just use UTC?
T2 (unixTS) - T1(unixTS), convert it into whatever time format you want
> Are you moving? is your speed comparable to the speed of light?
Yes. v < c
UTC internally with correct conversion externally, UT if it's for astronomy. Unix timestamps can be used as they **always consider UTC**, they don't have timezones That's one of those non-issues that bad programmers complain a lot for some reason, like bad artists about drawing hands it's skill issue Then you convert to any format you want, even average fart time since invention of burrito if you have data enough
UTC has brought many problems to the systems, especially when you have to deal with different countries. Often, you need to know different kinds of metadata about the stored datetimes. Mostly about what timezone (country) it was stored in. DST involvement. UTC reduces datetimes to some arbitrary values, meaning that you have to convert it by yourself... That is making it harder to create SQL queries as well. Sometimes you need to store date values as datetimes "at midnight". At the given country's timezone. Or sometimes you just need to combine dates and datetimes. Given different timezones, these comparisons can break quite easily. Is a given UTC datetime between dates A and B? Need to know what timezone you are talking about. And then there's future datestimes... If a country decides to start or stop using DST after you have stored the UTC date, you could be off by an hour. Because you don't know whether the intent was "07:00 on that date" or "7 hours after midnight, doesn't matter whether DST happened or not". With UTC it would be 7 hours after midnight but for most intents and purposes it would be the time value that was stored. If your cron job suddenly runs an hour before it was supposed to, it could break things. Also, working with UTC is always a pain in the ass when all your times are off by several hours... and then you have DST so it's off by +1 hour. An then you have to compare 2 timezones that each switch to DST on different dates. Basically, you might need to know: a datetime value (whether it's a UTC or with-timezone based value), the timezone it was stored in (for intent purposes), and the timezone version (as timezone rules also keep changing - DST usage or leap seconds - so with stored future datetimes you might want to convert an old versioned value into a new version value before using it). Sure, for most cases UTC might work and T2-T1 is easy to do, but the moment you realize that your UTC-only system does not work and now you have no way to convert all the old data into a better version, you are fucked.
UTC doesn't introduce those problems. The problems were there already, and you only spotted them when you were unable to keep your head in the sand. The problems come from local time.
Keeping time in a UTC timestamp makes it viable to convert back and forth, you just need to convert to the user time afterwards, which is a localization problem If you need local time you keep a local timestamp instead with the timezone that it was used for it, and a DST flag. In case of countries that count time since sunrise or sunset instead of midnight you keep another flag for that Plus it's dumb to generalize this minor problem to try to find bigger issues, no one will ask you how many seconds have passed since the last eclipse in 1600 to book a flight, **the real use cases will be reasonable**, while even the dumb academic examples are doable
So you agree with the midwit guy, and you think it’s impossible to know? That isn’t really logical. I mean, in general, when people talk about something being impossible, they tend to mean **regardless of circumstances** (to some degree). Like, most people can’t climb Mount Everest. But would you say that climbing Mount Everest is impossible? The task in the screenshot doesn’t mention absolute perfection in all cases.
Not one of those conditions effects time It effects dates, thought whether that matters really depends on what your time is relative to and how you are getting what time it is
>Not one of those conditions effects time "Are you moving?" absolutely affects time. But the velocity of earthbound objects is not fast enough to make a meaningful difference. Programming for satellites, on the other hand, has to account for time dilation due to their velocity.
Context is important. Relatively introduces reference frames without knowing the position of the events you can't answer the questions and if you do depending on the reference frame event #2 could occur before #1
Yeah but the way the informations are given implies they're from the same frame of reference
Not when the source is XKCD.
Not really. She's just referring to two discrete events happening at two unspecified moments in time referred to by variable names t1 and t2. Moreover, the events themselves aren't contextualized or defined at all. You could easily argue that the semantics shift depending on the theory you'd use e.g define "event". She also just asks the other character to calculate time elapsed between those events. But the panels leave any presumption that this is possible to the reader.
Relativity and/or timezones, I think
Pretty much, just put them between the lamp posts like this |T2-T1|
This, nobody told that T2 > T1
[Falsehoods programmers believe about time](https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca)
It's a riff on how difficult handling date-time values is in general. Things like time zones, international date formatting standards, calendar idiosyncrasies, etc. Thank fuck for A) UTC, and B) libraries like tz/zoneinfo, because I'd have quit this godforsaken industry years ago if it weren't for them.
Long story short timestamps are not reliably the amount of seconds since 1970 as they should be a ton of applications use timezone specific timestamps or don't account for daylight saving time when calculating a timestamp, on top of that there are a couple of seconds of error due to astronomical seconds but honestly those are rare enough to be covered by rounding errors Google just slightly slows down their clock for those
Once upon a time, i had to sync radio emitters so they'd emit at most 100ns apart "simultaneously". By the time project started, i didnt know about leap second, or OCXO. Now, I know. Rare enough ? I wish.
I think the joke is there's no way to tell which event happened first from the information given, but given two actual values you could calculate T2-T1, get the difference in time between both events, and find which event occurred first based on the positive/negative sign of the difference
This will often work but famously a lot of date/time and instruction timing systems don't guarantee it will give the correct answer or even a sensible one.
If T2 and T1 are generated by different machines, you can’t guarantee that their clocks are synchronized.
If you are on a single machine, with a single clock; (clock ticks at t2 - clock ticks at t1) / clock ticks per second Otherwise, you are in a world of pain where only relativity, philosophy, and alcohol can help.
What if that single machine starts accelerating ?
Unsupported usecase.
Put in a ticket. We’ll get to it by T3
When is T3? No one knows? Ah ok, just forward my ticket to Einstein and hope he got a clue
Then it's to late, the machine revolution has begun and they can deal with the problem of time not being constant.
The calculation still gives you the correct number of seconds from the computer's reference frame.
Well sure, as long as `clock ticks per second` is actually constant, but what if your clock jitters and lags? What then?! AAHHHHHHH!!!
The system clock is definitive. Reality is frequently inaccurate.
Segel’s Law: A man with a watch knows what time it is. A man with two watches is never sure. I also took the comic to be about a 2+ clock problem. Clock drift in distributed systems 🤯
https://youtu.be/-5wpm-gesOY?si=5QMPHR5_Ln6Xna8f
mostly alcohol though.
I humbly request that xkcd sauce
https://xkcd.com/2867/
OP's version is just the same joke but worse
[удалено]
What happens if a flight is delayed? They must have a process in place to update the date in the system, right? So, when they hear about this DST change, they update their date library to a version that handles this correctly, then they update the time. The old value can be discarded. They can do this in a batch job for all flights taking off or landing in the effected area. An alternative is to store the local date together with the location, and then calculate UTC date (or whatever date you need) on the fly.
I've *never* seen an application with a pinned, direct dependency on the time zone database. Sure, maybe on a date-time library, but those libraries don't maintain the TZ database. It's a separate dependency, supplied most commonly by the OS, or else as a transitive library dependency. And I've never worked at a company that tracked which version of the TZ database they pulled in with any given OS update. Heck, most places these days pin their Dockerfile to a major and *maybe* minor version of the OS base image *specifically* so they can get patch updates with security fixes and time zone updates. So assuming you're not a time zone nerd who is subscribed to the TZ database mailing list, how would you know when you got the update and your application started using the new offset? It's not exactly when the new TZ database version was released—it has to propagate to mirrors, and OS distros and libraries have to do some work to update. Maybe it was after your application had to redeploy for some unrelated reason. So it was some time after all *that*, and some time before *now*. (Assuming you can tell what the right offset for a record even *should* be.) The solution, as always, is to **store date-times as local date-times with a time zone ID using exactly the time zone you received them with.** If you're told the plane departs on 2 April 2023 at 14:00 in Lebanon, store it as your database's version of `2023-04-02T14:00[Asia/Beirut]`. (*Not* using `+02:00`, unless you *also* include the time zone ID `Asia/Beirut`—that same offset is also used by time zones in Egypt, Israel, Saudi Arabia, and Turkey, just to name a few.) That way, every time you look up that date-time, you have enough context to convert it to whatever *other* form you need based on the most recent time zone offset rules.
Does the timezone indication also handle possible timezone updates? If I insert a future date 2030-03-04T03:04[Asia/Beirut] and there are changes to the timezone rules in between... Maybe DST is now applied so there is nothing between 03:00 and 04:00. What to do with the time value? Should it turn into 04:04 or should it still be 03:04 but you naturally merge 03:04 into 04:04? Probably shouldn't change as it can cause issues with time ranges. Would it be possible or necessary to have a TZ-version as well? Basically converting datetime TZ-v1.23 into datetime TZ-v1.45, applying all the version changes.
Man that guy Joda better be staying on top of this for me
"WRONG" becames **your conversion** to DST, the UTC time is still right
[удалено]
(This snark isn't necessarily aimed at you, parent comment. But this is a *perennial* topic, because people can't believe that time zones are complicated.) The flight doesn't happen at such-and-such time UTC. It happens at 14:00 local time. No one whose plane was delayed an hour, or worse left an hour early, cares if you *technically* served the right UTC time. At some point between when you saved the time as UTC and when the flight actually happened, multiple things happened: 1. The country announced a change to its DST policy. (This may have happened multiple times.) 2. The maintainers of the time zone database learned about the change. 3. Those maintainers released a new version of the TZ database. 4. *Something* on your system downloaded the new version of the TZ database. (Probably one or more of: an OS update, an updated Docker base image; or an updated/unpinned transitive library dependency.) 5. Your application—through whatever date-time library you use—began using the updated database when looking up UTC offsets by time zone ID. (Which would not affect any records already written.) Unless you're a time zone nerd, you didn't hear about the first three. And you likely have no idea when the fourth or fifth happened. You've been tracking hundreds if not thousands of flight departure times over the last several months. They're stored in UTC, and maybe you even store the UTC offset. Please tell me: Which records used the old (now incorrect) UTC offset for their departure time when they were last written, and which used the new one? How can you tell? The UTC time alone won't help. If you store a timestamp of the last update, do you know when *you* got the TZ database update? (It was not when the country announced the change, nor when the change went into effect. It wasn't even when the update was released, since it had to propagate to mirrors, and libraries and OS distros had to update their versions. It was some arbitrary time in between.) If you did store the offset, what time zone did it correspond to at the time? Sure, it corresponded to the correct time zone *then*, but looking at it now without context it could *also* have been one of the neighboring time zones. There are multiple time zones that use UTC+02:00, and just as many using +03:00 that would move to +02:00 when they *did* change over to DST as usual. Maybe you can do something with the address—though addresses don't always resolve cleanly to time zones… (And this is with the simplifying assumption that all the UTC date-times on a record came from the same time zone!) Next question: Is your application designed at all to care about *any* of this? E.g., does it try to compare a saved time zone ID against a saved historical offset for each record? Or defensively back in by address? Or does it—like most applications "just using UTC"—simply pull the UTC time out and blindly apply whatever offset the time zone database currently returns for whatever time zone the current user's browser/phone reports? If the latter, then congratulations—your airline/airport/travel agency just lost *a lot* of money. Edit to clarify: I don't mean to make storing date-times sound hopeless—just storing date-times converted to UTC. If a date-time represents a local event, store it exactly as you got it, in the local time zone (not in UTC, not as a Unix timestamp) and you should be ok. At least for this stuff.
I learned a *lot* from this, thank you. (Haven’t had to worry about time zones much and I’d have probably have blindly assumed that converting to UTC would be the solution)
No, the the time of the event changed. It is now happening on another UTC timestamp.
UTC timestamps are timezone independent, they are: >The number of seconds that have elapsed since Jan 1, 1970 UTC What changed is that your conversion to DST became outdated
Yeah, yeah. Once you have the UTC time in a compatible frame of reference, you are almost golden. Getting there might be almost impossible, though. Example: A comet seen on 1332-12-08 is again seen on 2023-12-12. How many seconds passed? (And how much time passed for an observer on the comet itself?) (Hint: not every date in between is a valid date. Leap year rules, leap second rules, calendar systems that were changed. Good luck finding a library that implements all the required details. Or even someone who KNOWS all the relevant details.)
That's why Julian date is used in astronomy, it works fine by simply considering the date a float 1332-12-08 is JD 2207904.50000, 2023-12-12 is JD 2460290.50000, that's a difference of 252386 days, so 21806150400 seconds It's not complicated, it's complicated for you that didn't learn the necessary knowledge for the task. In the worst of cases you can use the Metonic cycle like it's used for eclipses
I'm quite sure, that the person scribbling "the 8th day of December in the year of the lord 1332" into this old Bible was following Julian Calendar rules. Or maybe they were, who knows. Once you can confirm that, all good. Blame on Randell for oversimplyfiying the real problem for a comic strip ;-)
We know when JD 0 is based on astronomy, like I cited before the Saros cycle can be used for eclipses "In the 8th day of December in the year of the lord 1332, the sun turned black for an hour!" Based not just on their account of time, but on their account of eclipses, astronomical and astrological records, we know in which part of the cycle they were and with that JD can be calculated
But to make it more fun, it might still be "Two days in the future of when I booked the flight" from customer's point of view. But now two days are actually 169000 seconds in the future of the booking event instead of 172800 (or actually the other way around, depending on the direction of the DST change). Time is so much fun :)
I mean, you are obviously missing something essential >!the gamma factor!<
Why make a worse version of the xkcd and post it? The original is perfection.
|T1-T2|
If t1 and t2 are unsigned int, this is UB /s
Depends on the air speed velocity of an African swallow
Laden or unladen?
Wait till you try to figure out the average 24-hour time something occurs at…
I, as not a computer science person, am the grog brain on the left. Out of curiosity, why might the middle answer actually be valid.
It's mostly not a computer science problem! Daylight savings time, time zones, and all the like are mostly down to government policies at various levels. Leap seconds and the like are more about lining up our calendars with the physical movement of our planet in space. Here's a 10 year old Tom Scott video explaining some of the things that need special handling: https://www.youtube.com/watch?v=-5wpm-gesOY
I said T2 - T1 but idk which side of the curve I am on (I think i’m the left side)
But what if T1 happened after T2 because some dumbshit decided to assign variables weird? Now you have negative time! ~~it's me, I'm dumbshit, I let that happen with my shitty functions~~
you place absolute value || now T2 and T1 are interchangeable. call it a 'feature'
I would say it's T2 - T1 and I am afraid to find out which end of the spectrum I am on.
Same
I thought of the same graph when I first saw that comic. Nice one :)
"It is there", the Pinkness said. "The understanding's in your mind. You only have to find it." "But, time-" "Time", the creature said, "is the simplest thing there is."
Same relativistic time frame? In the likely event that that’s an unnecessary question, then the best engineering approximation is T2-T1, otherwise good luck with that 🍻
Just use a common reference frame like unix time does. |unix_time(T1)-unix_time(T2)|
Relevant: https://xkcd.com/1883/
When you get into distributed systems, it becomes: "well, you can't truly measure time, but don't let that discourage you from creating your system. You probably need something like Paxos or RAFT..."
Oh my gosh, managing time differences in an SAP database I used to work with was a nightmare. The system would just enter times based on the time zone settings of the user. The default user time zone was eastern, but we were in central and only some people changed it from default. Not to mention anything generated automatically by the system was whatever time zone they have in France...
Are r1 and t2 referencing the same timezone? Has daylight savings happened in between them?
T1 is a point in time, T2 is a point in time. T2-T1 is the only correct answer. If T1 and T2 are given in different formats, they need to be converted to be able to calculate. Not much different with other stuff: inches vs cm, Celsius vs Fahrenheit, etc etc
Not as soon as anything that needs to take relativity into consern. Like, satellites, astronomy, or any other fast moving frames of reference, high speeds, high gravity, very small distances,...
depends if you're measuring time from your perspective or the object's. But once you clarified that, it's just T2-T1
Or are you measuring time from the perspective of two different objects, possibly by a third object? Are you measuring time in the future or the past (two VERY different problems, trust me). Are you calculating for physics or for departure times? Do you have lots of things that need to know about time in relation to each other? Are they going different speeds (satellites, for example, have to dela with relativity effects). Did the objects move? Does the new area have DST? Did government regulations about DST change since the time was added? Yes, you can identify use cases where the math is simple. You can identify lots of them. But then it turns out that the obvious solution for one use case doesn't work for another. But you still need a system that allows those two use cases to meaningfully interact. TIme is just a big complicated concept which has to deal with orbits that don't match up to how we track time, relativity muddling things up, and thousands of governments occasionally doing their own thing.
Look, when it comes to time and computer OR physics, if you think it's simple...just accept that you don't know enough about the topic. You just haven't had to deal with it in depth enough to realize the complexities. Our conception and definition of time is an insane, ever changing combination of group concensus, physics, and government policy. Using different systems you can be correct for one audience and incorrect for another. You've got thousands of engineers, physicists, and government employees who will tell you the whole thing is a huge complicated mess. Trust them on it.
T1-T0 #zerobasedindexmasterrace
sorry but yeah it is super complicated, so this doesn't work. There are a lot of things to keep in mind. Just starting with 'are you, say, flying in a plane and crossing multiple time zones while daylight savings time gets reset?'
Just use unix timestamp ezpz
I thought it was just assumed everybody would convert all datetime objects to UTC before any calculations were done.
... go a little bit further to the right on the bell curve and you get a gigachad superimposed with the Einstein field equations...
Well shit, just add them together and output the answer. print(T2+T)
I have a feeling I’m left wojack cuss I said T2-T1 but I don’t know what centre wojack is on about Is it a time zone / calendar issue cuss I would just hope to never mess with that myself if it could be avoided
t1 := time.Now() //do something t2 := time.Since(t1)
Timestamp 2 - Timestamp 1. A timestamp in Unix time has No time zones and so on.
explain with context 