The whole problem results from people using the same time for user-display and time calculations. Display time is user-facing feature that Should Not Influence system time.
If people used https://en.wikipedia.org/wiki/International_Atomic_Time for software none of the problems related to calendars will occurs.
IAT has no leap seconds or any calendar corrections at all.
Insane complexity of calendrically correct date and time operations
111–120 of 146 posts
Re: Insane complexity of calendrically correct date and time operations
#112Wisdom and experience from senior hacker developer "Oh you are working with time and dates that is going to get "complicated"" Lets propose a new time format we could count the number of exoseconds since the beginning of the universe. Then convert that number to whatever native time format we want. Store that as a number and use that for conversion. Age of universe 4.415×10^17 seconds, 4.415×10^26 exoseconds
You are reinventing TAI64NA badly.
Re: Insane complexity of calendrically correct date and time operations
#113Earlier quoted context omitted.
What you want is probably TAI [1], Unix Time has leap seconds. [1] https://en.wikipedia.org/wiki/International_Atomic_Time
The one mistake with UNIX is that UTC is used. It should have been TAI, and leap second adjustment should have been handled by the timezone package (but at the time people weren't worried about leap seconds, so it's understandable). As it is, the system clock has to change . This is as bad as MSDOS time (and other systems which put localtime into the actual RTC). Using UTC as the time reference, independent of local…
You need to learn about Arthur David Olson's "right" timezones.
Re: Insane complexity of calendrically correct date and time operations
#114I invented this very regular calendar while I was writing recurring-scheduling software for a scheduling tool: https://calendars.wikia.com/wiki/6*6*10_regular_calendar It was my fantasy escape from the crazy irregularities of the Gregorian calendar.
Can you imagine the transition to that calendar? People wanting their two days off every five working days are one of the problems.
It will never happen.
The US can't even get on the metric system.
The UN couldn't even reform the calendar to have uniform quarters:
https://en.wikipedia.org/wiki/World_Calendar
http://strangeside.com/time-sabbath-on-tuesday-364-day-year/
Re: Insane complexity of calendrically correct date and time operations
#115I think on of the best attempts to fix calendar system was done by George Eastman (Kodak founder), who presented "International Fixed Calendar" created by Moses Cotsworth to League of Nations in 1923. At that time League of Nations was trying to redesign current calendar system and was accepting different proposals.
Unfortunately they failed to come to consensus between different calendar designs :(
https://en.wikipedia.org/wiki/George_Eastman
https://en.wikipedia.org/wiki/Moses_B._Cotsworth
https://en.wikipedia.org/wiki/International_Fixed_Calendar
https://en.wikipedia.org/wiki/International_Fixed_Calendar_L...
https://gizmodo.com/how-the-quest-for-a-perfectly-rational-c...
Re: Insane complexity of calendrically correct date and time operations
#116Earlier quoted context omitted.
Not wanting to be a complete BSD bigot, I can't actually remember if this broke in the {Free,Net,Open}BSD world as badly. The 2015 docs for FreeBSD don't help (oh, for a time machine) but go to "you can test what we do" which is good. https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-se...
Not to jump on the bigotry, but two of the three bugs mentioned in that comment were in proprietary software (Java and RRDNS) that merely runs on Linux. The hrtimer issue in 2012 was a real kernel bug though.
Java was open sourced in 2006.
Re: Insane complexity of calendrically correct date and time operations
#117Earlier quoted context omitted.
Frankly I'm bit confused why civil time in general is based on UTC instead of TAI. Except for astronomy, who does benefit from observing leap seconds?
Civil timekeeping is based on UTC because we want clocks and calendars to remain synchronised with the sun. It's not just astronomers who care about whether the sun is above the horizon. If you think about it, the solar day is the one unit of time that almost everybody cares about and pays attention to. If you screw up the day, you also screw up the week and anything else that is based on counting days. Why would you…
But offset of UTC for TAI is like 37 seconds or something poxy like that. Nobody cares about this, the sun moves too slowly for that to make any difference.
There's been talk of setting UTC=TAI for quite a long time and I think it'd make sense. It'd take so long for TAI to drift from the actual rising and setting of the sun that we'd probably all have standardised on Swatch Beats by then anyway.
Re: Insane complexity of calendrically correct date and time operations
#118Earlier quoted context omitted.
Especially when it's all stuff that's already been covered in very similar essays. Actually introducing good libraries and methods for handling these issues properly would be much more useful than a smug collection of fallacies and a tacked-on link to ICU at the end.
I don’t understand this objection.. the method to handle these issues is to use ICU / NSCalendar.
Or a runtime equivalent, e.g. the java.time package gets this stuff right.
Re: Insane complexity of calendrically correct date and time operations
#119Earlier quoted context omitted.
Not wanting to be a complete BSD bigot, I can't actually remember if this broke in the {Free,Net,Open}BSD world as badly. The 2015 docs for FreeBSD don't help (oh, for a time machine) but go to "you can test what we do" which is good. https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-se...
Not to jump on the bigotry, but two of the three bugs mentioned in that comment were in proprietary software (Java and RRDNS) that merely runs on Linux. The hrtimer issue in 2012 was a real kernel bug though.
The 2012 bug was a bad interaction between Java and thread locking in the Linux kernel. It affected MySQL as well. The 2009 bug was in the Linux kernel, in the logging code. The 2016 bug I mentioned was in Cloudflare's proprietary code and only had a big impact because so many websites use Cloudflare. There are zillions of other smaller leap second related bugs, these are only three of the most visible.
(btw, the word "bigotry" has a real meaning and this isn't it.)
Re: Insane complexity of calendrically correct date and time operations
#120Earlier quoted context omitted.
Civil timekeeping is based on UTC because we want clocks and calendars to remain synchronised with the sun. It's not just astronomers who care about whether the sun is above the horizon. If you think about it, the solar day is the one unit of time that almost everybody cares about and pays attention to. If you screw up the day, you also screw up the week and anything else that is based on counting days. Why would you…
But offset of UTC for TAI is like 37 seconds or something poxy like that. Nobody cares about this, the sun moves too slowly for that to make any difference. There's been talk of setting UTC=TAI for quite a long time and I think it'd make sense. It'd take so long for TAI to drift from the actual rising and setting of the sun that we'd probably all have standardised on Swatch Beats by then anyway.
Yes, the difference is 37 seconds now, but it's growing quadratically. It's quite possible that we'll change the way we express times and dates, but it's almost certain that we'll want them to stay in phase with the sun, and we'll probably want to stick with the SI second and with something like TAI. My guess is we'll continue to want a simple relationship between TAI (or its successor) and the civil clock time, something like the current relationship according to which they are a whole number of seconds apart. That implies that we'll need something like leap seconds (or leap minutes perhaps). There doesn't seem to be a reasonable alternative.