|
Suspicious Dish posted:i thought it was that it wasn't easily divisible by the rotation around the sun (exact year doesn't divide into exact day) That is fundamentally the reason, but since the Earth doesn't rotate at a constant rate we can't just have N leap seconds every M years, like we do for leap days. So it's more accurate to say that leap days roughly take care of the effect that you describe and that leap seconds deal with changes in rotation (also, whereas leap days are always positive, leap seconds can be negative!) QuarkJets fucked around with this message at 22:01 on Aug 19, 2017 |
#
?
Aug 19, 2017 21:57
|
|
|
|
| # ? Jun 8, 2024 06:57 |
|
|
QuarkJets posted:They're not pointless. They address the fact that the Earth's rate of rotation is not a constant Look at how inaccurate time zones are. Is 35 seconds of offset really that big of a problem?
|
|
#
?
Aug 19, 2017 22:02
|
|
|
Then there's Google's Leap Smear, where they slowly sneak in the extra second over a 24 hour period. I've never had to deal with that, but it sounds like the fun.
|
|
#
?
Aug 19, 2017 22:38
|
|
|
Dylan16807 posted:Look at how inaccurate time zones are. Is 35 seconds of offset really that big of a problem? Yeah like in several instances If you're navigating, doing cryptography, radio telescopy, again navigating, bombing things, space stuff, communicating, etc ... One is, "yeah we have to all agree on what time it is to function as humans in a society" and the other is more technical.
|
|
#
?
Aug 19, 2017 22:55
|
|
|
Dylan16807 posted:Look at how inaccurate time zones are. Is 35 seconds of offset really that big of a problem? Time zones are a whole different horrible mess, don't go acting like time zones being stupid and hosed up means that we can just ignore leap seconds and leap days Satellite navigation and communication systems don't give a poo poo about bumblefuck timezones but they do need celestial time to match up pretty well with atomic time ("pretty well" being much, much better than 35 seconds)
|
|
#
?
Aug 19, 2017 23:04
|
|
|
Nothing instills me with more confidence towards my bank than a 500 error page. Combine that with sending me a link to reset my password, that is incorrect. I'll be having a talk with a consultant tomorrow regarding that. In other news though:  edit: aaaaaaaaaaaaaargh.. "You're membership number". I'm not native speaker, but spelling errors of that caliber irk me to no end. 
canis minor fucked around with this message at 23:32 on Aug 19, 2017 |
|
#
?
Aug 19, 2017 23:04
|
|
|
I work in telecom and we use PTP and GPS timing all over the place because we need nanosecond level precision, but I'm not sure I understand what either of those timing systems would lose if we got rid of leap seconds. Not saying this to challenge the importance of leap seconds, just saying I don't understand. Edit: Oh nevermind, I missed the post about satellite communications needing celestial time to match up. I think I understand.
|
|
#
?
Aug 19, 2017 23:13
|
|
|
dougdrums posted:Yeah like in several instances No, no, I'm not arguing against precise time at all. I'm saying that where we need a precise time standard to micro and nanoseconds it should not have leap seconds, and who cares if the Earth's rotation is "wrong" by 35 seconds when that's constantly drifting anyway and smeared over zones an hour across. It especially should not have leap seconds because that encourages a "smear" technique that destroys all that hard-earned precision. QuarkJets posted:Time zones are a whole different horrible mess, don't go acting like time zones being stupid and hosed up means that we can just ignore leap seconds and leap days UTC already drifts up to .9 seconds off celestial time. Don't use UTC or TAI when you need celestial time.
|
|
#
?
Aug 19, 2017 23:34
|
|
|
Another option instead of leap seconds would be to gradually migrate time zone boundaries. Each leap second needs under half a kilometer's adjustment.
|
|
#
?
Aug 20, 2017 00:19
|
|
|
If we're going to do that I say get rid of timezones altogether.
|
|
#
?
Aug 20, 2017 02:12
|
|
|
sarehu posted:Another option instead of leap seconds would be to gradually migrate time zone boundaries. Each leap second needs under half a kilometer's adjustment. That doesn't actually fix things like geospatial pointing accuracy though Dylan16807 posted:No, no, I'm not arguing against precise time at all. Accuracy to within 0.9 seconds is fine in a lot of cases where accuracy to within 30 seconds is not fine. "Oh just always use celestial time" doesn't actually solve the problem because there aren't a lot of easy ways to accurately calculate celestial time, whereas keeping atomic time is just accepted practice now. Being able to translate accurately between the two means having your cake and eating it too: you get the extremely accurate time-keeping capabilities of atomic time coupled to the imperfect-but-still-very-accurate utility of accurate geospatial accuracy based on celestial time We use leap seconds because that's actually more accurate than trying to maintain celestial time via other means QuarkJets fucked around with this message at 02:24 on Aug 20, 2017 |
|
#
?
Aug 20, 2017 02:17
|
|
|
Thermopyle posted:If we're going to do that I say get rid of timezones altogether. I've been arguing for this position for awhile. Nobody ever agreed with me before. 
|
|
#
?
Aug 20, 2017 02:24
|
|
|
Definitely we should get rid of timezones but that doesn't mean you can get rid of leap seconds
|
|
#
?
Aug 20, 2017 02:25
|
|
|
Personally I just use Swatch internet time.
|
|
#
?
Aug 20, 2017 02:27
|
|
|
A contractor we're hiring asked if we want tests written with JUnit or Mockito.
|
|
#
?
Aug 20, 2017 02:27
|
|
|
Fergus Mac Roich posted:Personally I just use Swatch internet time. This man gets it.
|
|
#
?
Aug 20, 2017 03:44
|
|
|
TooMuchAbstraction posted:I've been arguing for this position for awhile. Nobody ever agreed with me before. I agreed with you without ever having the conversation, and I think China did as well.
|
|
#
?
Aug 20, 2017 04:59
|
|
|
Thermopyle posted:If we're going to do that I say get rid of timezones altogether. Exactly. Why should anyone be in a different timezone than mine? My timezone is the best and it beats all of the others combined. EST rules.
|
|
#
?
Aug 20, 2017 05:20
|
|
|
Too bad it's currently EDT and not EST!
|
|
#
?
Aug 20, 2017 05:30
|
|
|
I'm just reading all this mess about time zones and I'm just wondering what kind of mess that will happen when we get to colonies on other planets. I also fully expect that at least one colony will declare independence from Earth and declare that the year of their founding will be their Year 1.
|
|
#
?
Aug 20, 2017 05:31
|
|
|
HardDiskD posted:I'm just reading all this mess about time zones and I'm just wondering what kind of mess that will happen when we get to colonies on other planets. I also fully expect that at least one colony will declare independence from Earth and declare that the year of their founding will be their Year 1. Well, for starters, the time is not really going to sync because of the different gravity and the changes in relative velocity throughout the various parts of the respective orbits.
|
|
#
?
Aug 20, 2017 05:44
|
|
|
QuarkJets posted:Accuracy to within 0.9 seconds is fine in a lot of cases where accuracy to within 30 seconds is not fine. quote:"Oh just always use celestial time" doesn't actually solve the problem because there aren't a lot of easy ways to accurately calculate celestial time, whereas keeping atomic time is just accepted practice now.
|
|
#
?
Aug 20, 2017 07:16
|
|
|
ThisIsNoZaku posted:A contractor we're hiring asked if we want tests written with JUnit or Mockito. Heh. Suggest Docker just to mess with them.
|
|
#
?
Aug 20, 2017 08:56
|
|
|
Dylan16807 posted:That's 150 feet of slop, I don't know. And if you're keeping your clock within a second you probably have access to a network or GPS, both of which can give you a much more precise offset than .9 seconds. GPS time is just another kind of atomic time. Using GPS doesn't solve the problem of having to match two out-of-sync timekeeping systems. That's exactly why UTC was created: it includes the offsets necessary to bring atomic time in-line with celestial time. They only differ by the total number of leap seconds. Applications that use UTC but that need to be insensitive to the insertion of leap seconds are at fault for using the wrong timekeeping system; they should use something like GPS or TAI, which do not include leap seconds.
|
|
#
?
Aug 20, 2017 11:57
|
|
|
So after all this time talk, what is the best way to store it and retrieve it? I have some timestamps that I keep track off and they need to be represented in a GUI, with respect to the user's timezone. So store them as UTC in the DB and let the GUI format it?
|
|
#
?
Aug 20, 2017 12:24
|
|
|
Mr Shiny Pants posted:So after all this time talk, what is the best way to store it and retrieve it? I have some timestamps that I keep track off and they need to be represented in a GUI, with respect to the user's timezone. Do not EVER deal with timezones at all and store datetimes without timezones unless you have a specific usecase of having to coordinate between multiple ones. In that case first make sure that all input sources add the correct timezone and then yeah, storing it UTC is not a bad idea. ISO-8601 standard datetime Strings, which you should use if your db doesn't have a specific datetime format, allows you to store them with timezones, like 2017-08-20T05:53:45+01:00 but doing so means you need a lot of checks and calculations to translate things into whatever timezone the output wants. UTC makes it simpler.
|
|
#
?
Aug 20, 2017 12:50
|
|
|
Mr Shiny Pants posted:So after all this time talk, what is the best way to store it and retrieve it? I have some timestamps that I keep track off and they need to be represented in a GUI, with respect to the user's timezone. Store UTC as Unix time in a 64 bit signed integer. Do not roll your own library for conversions, existing libraries to format Unix time already deal with leap seconds and that kind of nonsense.
|
|
#
?
Aug 20, 2017 14:34
|
|
|
HardDiskD posted:I'm just reading all this mess about time zones and I'm just wondering what kind of mess that will happen when we get to colonies on other planets. My dim recollection of relativity says that simultaneity is kind of bunk anyway; it's just not as noticeable on Earth because the distances are too short. And even then, GPS satellites have to have some kind of compensation. When the distances are bigger, the issue gets thornier. The Moon is ~1 light second away -- but other planets will have a much more widely-varying time-delay. I expect that each planet would end up instituting its own local time and have a system library that'd do things like "If I were to send a message to this location on Earth right now, when would it arrive in their time system?"
|
|
#
?
Aug 20, 2017 15:05
|
|
|
The people who developed and maintain datetime libraries are unsung heroes.
|
|
#
?
Aug 20, 2017 16:30
|
|
|
Treating time as UTC epoch timestamps isn't always suitable when you're like tracking, like, a weekly meeting room schedule has to stay at the same wall clock time across daylight saving bullshit. But that's probably just a thing you want to avoid having to do.
|
|
#
?
Aug 20, 2017 17:02
|
|
|
Vanadium posted:Treating time as UTC epoch timestamps isn't always suitable when you're like tracking, like, a weekly meeting room schedule has to stay at the same wall clock time across daylight saving bullshit. But that's probably just a thing you want to avoid having to do. Singular meeting events should probably timestamped with time zone, while the recurring event definition should be made with timezone-less times. Holidays and similar whole-day calendar events are also defined on dates without times or timezones.
|
|
#
?
Aug 20, 2017 17:14
|
|
|
What is a "timezone-less" time? UTC? While a "timestamp with time zone" is local time?
|
|
#
?
Aug 20, 2017 17:43
|
|
|
Vanadium posted:Treating time as UTC epoch timestamps isn't always suitable when you're like tracking, like, a weekly meeting room schedule has to stay at the same wall clock time across daylight saving bullshit. But that's probably just a thing you want to avoid having to do. I don't see why this couldn't be handled with UTC epoch timestamps. mktime in the C standard library handles daylight savings.
|
|
#
?
Aug 20, 2017 17:52
|
|
|
my girlfriend is Legos posted:I'm writing some front end stuff for a partner of ours and found a bit of a peculiarity about their API. After first trying it out and fetching some data, on a hunch I decided to check the UNIX timestamp it returned. Sure enough, it was off by two hours. Their server is located in CET, so I figured they probably accidentally used DateTime.Now instead of DateTime.UtcNow when generating the timestamp. Fair enough, I guess that's an understandable mistake. I asked one of their developers if he knew about it, and turns out that nope, it was a very deliberate decision to return an integer named 'Time' that looks exactly like a UNIX timestamp but is secretly the server's local time minus 1/1 1970 00:00 UTC and thus doesn't conform to standard, because "in 99% of cases you want local time". What do they on the switch to/from daylight savings time?
|
|
#
?
Aug 20, 2017 18:09
|
|
|
QuarkJets posted:GPS time is just another kind of atomic time. Using GPS doesn't solve the problem of having to match two out-of-sync timekeeping systems. quote:That's exactly why UTC was created: it includes the offsets necessary to bring atomic time in-line with celestial time. They only differ by the total number of leap seconds. Applications that use UTC but that need to be insensitive to the insertion of leap seconds are at fault for using the wrong timekeeping system; they should use something like GPS or TAI, which do not include leap seconds. Thermopyle posted:The people who developed and maintain datetime libraries are unsung heroes.
|
|
#
?
Aug 20, 2017 18:12
|
|
|
fleshweasel posted:What is a "timezone-less" time? UTC? While a "timestamp with time zone" is local time? It's either a string like "08:15" or an integer for the hour and one for the minute. So if you want to store a recurring meeting schedule of "Weekly on Monday at 08:15" you store "Weekly," "Monday," and "08:15," instead of something like "Weekly, starting on 8/21, at 08:15 Pacific."
|
|
#
?
Aug 20, 2017 18:19
|
|
|
fleshweasel posted:What is a "timezone-less" time? UTC? While a "timestamp with time zone" is local time? Timezone is defined versus undefined. A wall clock time with no declaration of timezone is timezone-less, but you need to interpret it within some later-defined timezone to form a real timestamp. Imagine a cruise ship crossing the Pacific ocean, it has a sign posted: "Breakfast is served every morning from 7 to 10." Those times are timezone-less, because you need to interpret it in the current local time zone every day. Arguably it would also be better to post it as "from 7 am and the following 3 hours", to handle the case of crossing a timezone boundary in the middle of breakfast which could otherwise be interpreted as lengthening/shortening it.
|
|
#
?
Aug 20, 2017 18:23
|
|
|
Prev job used floats for time of day db fields. So like 5.3 was five thirty.
|
|
#
?
Aug 20, 2017 19:17
|
|
|
I am so glad all I care about is frame-by-frame timing.
|
|
#
?
Aug 20, 2017 19:19
|
|
|
|
| # ? Jun 8, 2024 06:57 |
|
|
https://web.archive.org/web/20170817113559/https://github.com/Microsoft/vscode/issues/32405
|
|
#
?
Aug 20, 2017 19:37
|
|