|
Has anyone considered not pointlessly loving around with clocks? my natural phenomena my daylight hours
|
#
?
Apr 15, 2018 14:52
|
|
|
|
| # ? Jun 6, 2024 03:33 |
|
|
Developers insisting that existing human phenomena should change rather than adapting systems to the real world is the most developer thing possible.
|
|
#
?
Apr 15, 2018 15:13
|
|
|
MononcQc posted:Developers insisting that existing human phenomena should change rather than adapting systems to the real world is the most developer thing possible. Empty quote
|
|
#
?
Apr 15, 2018 16:39
|
|
|
MononcQc posted:Developers insisting that existing human phenomena should change rather than adapting systems to the real world is the most developer thing possible. 
|
|
#
?
Apr 15, 2018 19:44
|
|
|
MononcQc posted:Developers insisting that existing human phenomena should change rather than adapting systems to the real world is the most developer thing possible.
|
|
#
?
Apr 15, 2018 19:46
|
|
|
pokeyman posted:Has anyone considered not pointlessly loving around with clocks? yes, almost every 6 months, in fact.
|
|
#
?
Apr 15, 2018 20:35
|
|
|
daylight saving time is pointless but leap seconds actually have a reason to exist
|
|
#
?
Apr 15, 2018 21:49
|
|
|
MononcQc posted:Developers insisting that existing human phenomena should change rather than adapting systems to the real world is the most developer thing possible. Developers insisting that other developers keep using their useless overcomplication is even more developer. Leap seconds are a solution to a problem that doesn't exist. They're not a description of human behavior, because no one would ever notice if leap seconds just stopped being added (as has been proposed, voted on, and deferred for like 20 years now).
|
|
#
?
Apr 15, 2018 23:40
|
|
|
MononcQc posted:Developers insisting that existing human phenomena should change rather than adapting systems to the real world is the most developer thing possible. Yeah but daylight savings and other area-unique time differences are stupid and bring nothing but confusion, development aside. Leap seconds of course are a separate matter.
|
|
#
?
Apr 16, 2018 00:34
|
|
|
Leap seconds make timekeeping more accurate. Daylight savings makes timekeeping less accurate (in regards to solar noon/midnight) for a majority of the year.
|
|
#
?
Apr 16, 2018 01:24
|
|
|
Personally, I don't give a poo poo about when solar noon is, but I'd rather not walk to work in the dark.
|
|
#
?
Apr 16, 2018 01:38
|
|
|
Taffer posted:Yeah but daylight savings and other area-unique time differences are stupid and bring nothing but confusion, development aside. Leap seconds of course are a separate matter. Governments doing stupid poo poo with their time zones is a problem that the standards bodies can't solve. Until time nerds take over the world, you are always going to have to convert to and from civil time. Leap seconds, on the other hand, are an entirely self-inflicted wound. Who are they even for? Are there any people who:
|
|
#
?
Apr 16, 2018 03:48
|
|
|
b0lt posted:Governments doing stupid poo poo with their time zones is a problem that the standards bodies can't solve. Until time nerds take over the world, you are always going to have to convert to and from civil time. There are countless groups that require UTC-UT1 to be less than 30 seconds, yes. There is a shitload of legacy equipment in the world that assumes UTC is being kept to within a second or two of UT1 You could stop updating UTC and let the two systems drift, but without prep work it would break a lot of things in the astronomical and satellite communities. A lot of important things, things that would effect a lot more than just those communities. So yeah, it's fixable, but not easily fixable
|
|
#
?
Apr 16, 2018 04:17
|
|
|
MononcQc posted:Developers insisting that existing human phenomena should change rather than adapting systems to the real world is the most developer thing possible. If the historical list of reasons to gently caress with time include things like "ships" and "trains" and "atomic clocks", then "computers" doesn’t feel ridiculously out of place on that list.
|
|
#
?
Apr 16, 2018 04:58
|
|
|
pokeyman posted:If the historical list of reasons to gently caress with time include things like "ships" and "trains" and "atomic clocks", then "computers" doesn’t feel ridiculously out of place on that list. The more accurate timescales that involve leap seconds only exist because of computers though? Besides, the concession to change leap seconds to be integers was made about 50 years ago to ease programmer implementation issues, so you can't expect much more than that.
|
|
#
?
Apr 16, 2018 05:04
|
|
|
pokeyman posted:If the historical list of reasons to gently caress with time include things like "ships" and "trains" and "atomic clocks", then "computers" doesn’t feel ridiculously out of place on that list. The keepers of POSIX time could choose to not have it represent UTC; there's nothing forcing them to do that. It would be lovely of them but they could do it.
|
|
#
?
Apr 16, 2018 05:17
|
|
|
fishmech posted:The more accurate timescales that involve leap seconds only exist because of computers though? Not sure I follow. quote:Besides, the concession to change leap seconds to be integers was made about 50 years ago to ease programmer implementation issues, so you can't expect much more than that. This is why the Wikipedia article says that the leap second system started in 1972? And for the ~decade leading up it was more like what is today called smearing?
|
|
#
?
Apr 16, 2018 05:33
|
|
|
pokeyman posted:Not sure I follow. It took computers in order to be able to do things like invent atomic clocks and determine the rate leap seconds would even be needed. Yes, sort of. You would have things like leap thirds of a second or other fractions done much more frequently, which was eventually dropped in favor of doing leap seconds only every 6 months and at whole-second steps. This was done because of the increasing use of computer equipment, especially on networks, and the havoc that could potentially be wreaked by the fractional movements
|
|
#
?
Apr 16, 2018 05:47
|
|
|
I guess I forgot to keep in mind that it can always be worse. edit: what a mess. So Unix time doesn’t have leap seconds until POSIX specifies UTC, but UTC at the epoch (1970) might not mean the same thing as POSIX-specified UTC (1972) except it doesn’t really make a difference. Also came across djb's blatherings about TAI and found quote:Thanks to my lobbying, Internet mail messages are now allowed to have 5-digit years. pokeyman fucked around with this message at 06:16 on Apr 16, 2018 |
|
#
?
Apr 16, 2018 05:54
|
|
|
Jabor posted:Personally, I don't give a poo poo about when solar noon is, but I'd rather not walk to work in the dark. This happens anyway once you get a reasonable distance away from the equator, daylight savings or not. I must have done that thousands of times; it's really not the end of the world. Leap seconds are also stupid. There is no reason for human day-to-day timekeeping to be that calibrated to celestial movements. It would be better to wait a couple of centuries, then skip a leap year or something.
|
|
#
?
Apr 16, 2018 11:08
|
|
|
Athas posted:This happens anyway once you get a reasonable distance away from the equator, daylight savings or not. I must have done that thousands of times; it's really not the end of the world. Day-to-day timekeeping already doesn't care about leap seconds, aka you wouldn't adjust your watch for them.
|
|
#
?
Apr 16, 2018 11:18
|
|
|
Athas posted:This happens anyway once you get a reasonable distance away from the equator, daylight savings or not. I must have done that thousands of times; it's really not the end of the world. the seasons are all messed up anyway we should reset the year at some point so winter (snow and ice) is late november - december - jan instead of February -March-april
|
|
#
?
Apr 16, 2018 12:00
|
|
|
Erm we experience more snow/ice in Jan/Feb/Mar.
|
|
#
?
Apr 16, 2018 12:21
|
|
|
pokeyman posted:I guess I forgot to keep in mind that it can always be worse. "Don't contribute to the Y10K problem" he says, while blithely setting up the Y100K problem. Smh.
|
|
#
?
Apr 16, 2018 12:50
|
|
|
Athas posted:This happens anyway once you get a reasonable distance away from the equator, daylight savings or not. I must have done that thousands of times; it's really not the end of the world. New Zealand is pretty far from the equator, but the point of daylight savings time is that the sun is up by like quarter to 8 even in the middle of winter. So you're not walking to work in the dark unless you spend like three hours a day commuting or have a job that works odd hours. And of course the actual "savings" part of daylight savings is so that you actually get to use the hour of daylight that would otherwise be wasted at 5am during the summer when very few people are awake.
|
|
#
?
Apr 16, 2018 14:35
|
|
|
Daylight savings is great. Sleeping through three hours of sunlight in the morning would be stupid. One's opinion of daylight savings may depend on hour far north you are however.
|
|
#
?
Apr 16, 2018 14:45
|
|
|
necrotic posted:Erm we experience more snow/ice in Jan/Feb/Mar. Yeah, lemme tell you about the foot of snow we got over the weekend :| HappyHippo posted:Daylight savings is great. Sleeping through three hours of sunlight in the morning would be stupid. Stupid would be not adjusting business hours
|
|
#
?
Apr 16, 2018 15:15
|
|
|
HappyHippo posted:Daylight savings is great. Sleeping through three hours of sunlight in the morning would be stupid. Yeah, it's great. I love when the sun sets at 3pm. gently caress the morning, give me some light in the evening please.
|
|
#
?
Apr 16, 2018 15:26
|
|
|
Kilson posted:Yeah, it's great. I love when the sun sets at 3pm. gently caress the morning, give me some light in the evening please. You realize that the sun setting early is the non-DST part of the year, right? DST makes the sun set later. I'd be down for permanent DST though, some jurisdictions do that.
|
|
#
?
Apr 16, 2018 15:29
|
|
|
You can stop loving around with daylight savings time and just change your timezone. 
|
|
#
?
Apr 16, 2018 16:45
|
|
|
Obviously the only sane solution is to blow up the sun.
|
|
#
?
Apr 16, 2018 16:51
|
|
|
Jabor posted:Personally, I don't give a poo poo about when solar noon is, but I'd rather not walk to work in the dark. Tell your boss you'll be in when it's light out and work 8 hours from whenever that is.
|
|
#
?
Apr 16, 2018 17:22
|
|
|
HappyHippo posted:You realize that the sun setting early is the non-DST part of the year, right? DST makes the sun set later. Since DST is like 8 months of the year now, I consider it the default. I actually feel like the clocks should go the opposite way that they do.
|
|
#
?
Apr 16, 2018 17:37
|
|
|
When mentioning universal time, be aware of - UT0: no longer used, was based on astronomical observations of average solar time that had issues with calculations of the point of the observer vs. the earth's polar motion - UT1: patched up UT0 to care for polar motion, using better frames of reference. That's what GMT was. - UT1R: patched up UT1 to account for variations of tides - UT2: patched up UT1 to account for seasonal variations - UTC: instead of observations, is based on atomic clocks. To keep it in step with UT1, leap seconds are used, bridging the distance between atomic clocks and the rest In a nutshell, use the following if: - UTC: you want humans to use your things and understand them; You can trace UTC to be an improvement over UT0 and UT1 requirements and observational systems, using a bridge of leap seconds to play ball with a bunch of legal frameworks and civil expectations that time be based to astronomical observations without binding the easy accounting of time to these resources. Anyway the whole point is to make sure that over time, a solar day remains a solar day (and in 200 years from now, you don't end up with sunset and sunrise times that drift drastically) while also having an atomic clock. - TAI: a continuous monotonic clock that don't need no leap seconds based on fancy averages of atomic clocks. There's a known offset from UTC though (~37 seconds right now), so if you want to convert timezones and dates to deal with humans, you'll need to do some more math. Oh also it is based off gravitational properties of earth, so it's not necessarily a good thing if you're thinking space travel. - GPS time: as sent by GPS satellites; it is also a continuous monotonic clock, but has no correction for leap seconds either. It has a 19 seconds offset from TAI. GPS receivers displaying time to humans have to insert and handle leap seconds, but be warned that after 255 of them, it can't really account for more right now. - Unix Epoch: you a linux person who wants no questions asked but may be wrong about things you have when converting with some unit. Kind of assume that through NTP and poo poo math, you get a clock that is roughly-atomic-looking by virtue of being sync'd to UTC and disregards leap seconds Since civil systems were simplified by tying them to UTC (rather than GMT and other local observations), if you communicate with users legally, you must convert to that one if you deal with people. If you don't have to talk to people or report dates, it's simple enough to just use TAI or GPS clocks to get a good frequency. But if you use them, you get basically similar problems to unix epoch (having to match UTC differences) no matter what. Turns out there's a big deal about ensuring midnight is actually midnight and folks liking SI units are trying real hard to regular stuff. You can't really get away from that. All discussions of abolitions of leap seconds I could read on tend to only replace them by smearing or eventually inserting leap hours. If you like that stuff, the cleanest resource I've found so far outside of books is https://www.cv.nrao.edu/~rfisher/Ephemerides/times.html Oh also if you want to see worse systems, look back in history; the observational lunar calendar of the ottoman empire is a real fun one there, since taxation was based on crop, but a lunar calendar to calculate taxation years would drift and sometimes land in a case where no taxes could be levied. Pretty much all observational systems of the past were way worse than current ones. This is a good time to be dealing with time, we're just really confused about it because we're generally worrying about the local system (which is exactly why timezones and DST and all that poo poo exists to be painful) but working with global systems without understanding them too much. My best tips would be this: a) when measuring short time intervals, use a monotonic clock on your system. They're low accuracy over long periods of time, but the best source of information for short intervals. This is for time differences in the range of nanoseconds to a few seconds. b) when dealing with long intervals, sure, use unix epochs, but mostly use them for differences of time in seconds. Basically avoid using them as a long-term absolute storage for events, but use it as a relative mechanism to count the time interval between sets of events. c) when dealing with pinpointing the presence of an even in time, use UTC, since "pinpointing in time" is generally a very human activity that computers don't care about, and the differences on the millisecond-level or below won't matter too much. UTC will account for leap seconds, users will be happy to know their poo poo works with the civil calendar, and that's it. d) when wanting to create a total order between events based on time, you must use TAI or GPS time (or any other continuous time sequence -- maybe UTC with time-smeared leap seconds via NTP works here) + a confidence interval representing an uncertainty level of NTP on your systems. In case of conflicts (two stamps within that interval), then you add a logical clock (see: lamport clocks) to impose additional ordering e) if you schedule events in the future for people, don't use UTC! Use their local time based on their locale (city); since DST and even dates (see Samoa Islands switching timezones across the date line in 2012, or Brazil, which votes DST on a regional basis) can shift, you can't necessarily use timezone information to do calculations far ahead in time. Your system should use UTC and the locale information to calculate the user's time in the present, and then know if the event needs to be triggered when comparing them in their respective local times. Do give them the option to use UTC as a locale if possible, which works better when setting up phone or online meetings with people in various timezones. Special trap: prevent users from scheduling an event on an hour that doesn't exist due to DST in their local time, in the future. f) don't deal with gravitational and other relativistic factors and do not accept a job that asks for it
|
|
#
?
Apr 16, 2018 17:41
|
|
|
MononcQc posted:d) when wanting to create a total order between events based on time, you must use TAI or GPS time (or any other continuous time sequence -- maybe UTC with time-smeared leap seconds via NTP works here) + a confidence interval representing an uncertainty level of NTP on your systems. In case of conflicts (two stamps within that interval), then you add a logical clock (see: lamport clocks) to impose additional ordering Is there a reason why epoch wouldn't work for ordering events? It sounds like it meets the criteria but you didn't mention it here.
|
|
#
?
Apr 16, 2018 17:55
|
|
|
MononcQc posted:e) if you schedule events in the future for people, don't use UTC! Use their local time based on their locale (city); since DST and even dates (see Samoa Islands switching timezones across the date line in 2012, or Brazil, which votes DST on a regional basis) can shift, you can't necessarily use timezone information to do calculations far ahead in time. Your system should use UTC and the locale information to calculate the user's time in the present, and then know if the event needs to be triggered when comparing them in their respective local times. Do give them the option to use UTC as a locale if possible, which works better when setting up phone or online meetings with people in various timezones. Special trap: prevent users from scheduling an event on an hour that doesn't exist due to DST in their local time, in the future. We've recently run into problems with this in our scheduling software. Until recently our software was predominantly used within a single timezone, but now we have some customers with global reach, so various small issues have been cropping up. We let users schedule stuff that will start on a certain date, at a specified time, but the time it will come into effect depends on the local timezone of each installation, and each scheduled item may be applicable to installations in any number of different timezones. Users may believe the item will become active everywhere at the same time, but that's not the case. There are probably scenarios where the user wants it to be simultaneous and other scenarios where they don't. Currently it's a bit of a mess. One concrete thing we've done is make UI updates and server validation changes to allow scheduling content for yesterday's date, provided that there's somewhere in the world that hasn't reached the current date of UTC yet. I've later learned that this concept is called Anywhere on Earth. The point of this is to let users make changes that will come into effect immediately for installations that are behind UTC, even after UTC has rolled over to the next date. For instance, a user in UTC+10 might want to schedule something that should be effective in one hour for an installation at UTC-10, when the current UTC time is 01:00 AM, but this is only possible if the server has a grace period where it lets you schedule things that are "yesterday" from its perspective. I think software made in countries that span multiple timezones is more likely to get this stuff right from the get-go.
|
|
#
?
Apr 16, 2018 18:35
|
|
|
TooMuchAbstraction posted:Is there a reason why epoch wouldn't work for ordering events? It sounds like it meets the criteria but you didn't mention it here. On a single machine it can work if you can ensure that: a) the resolution is smaller than the number of events per call (i.e. microseconds may not be enough, you may need a software counter on top, but the OS can usually do that on clock counts anyway b) the time is monotonic, so the epoch cannot be rewound back in time (NTP allows that, so you can't be sync'd on NTP unless you also account for the ± time travel factor) On multiple machines, since clock rates and time settings may vary, you need something like NTP to ensure everyone is within the same kind of time margin for events. Since NTP can change the [perceived] clock speed or shift things forwards and back in time and that not all communication and syncing takes place at the same time at all nodes, you do require the ± confidence interval in time to be accounted for. MononcQc fucked around with this message at 18:47 on Apr 16, 2018 |
|
#
?
Apr 16, 2018 18:43
|
|
|
Ah, right, that does make sense. Fortunately the use cases I happen to be concerned with only care about events on single machines, and the events are infrequent enough that even millisecond resolution is more than we need.
|
|
#
?
Apr 16, 2018 18:51
|
|
|
Bug report: too many people adding an extraneous "s" to Daylight Saving Time
|
|
#
?
Apr 16, 2018 19:38
|
|
|
|
| # ? Jun 6, 2024 03:33 |
|
|
MononcQc that is some good poo poo, thanks for all that.
|
|
#
?
Apr 17, 2018 00:39
|
|