- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Out of curiosity, how many Israeli companies do actually use the Hebrew calendar as a basis for their accounting?
Admin
Your algorithm will be landing in..... 28 (days) x 24 (hours) x 60 (minutes) x 60 (seconds) Seconds time....
Which is exactly 28 days from now() which is as precise as it gets. I don't give a shit what the date or time will be when it happens, I just care that it happens on time.
Admin
It is common to use number of non-leap seconds for timestamp because leap seconds are irregular. However you didn't deal with the more important first point about months (and years) not having the same number of days. Because if somebody wants 72 months ago, it will be different number of seconds depending on from which point they want it. Even non-leap seconds.
Admin
I've just been reading about leap seconds and the controversy it causes: whether we should have them or not. Interestingly there is a similarity about ditching them to the idea of ditching Crontab, and if you can't see that the please see my post on the topic HERE
The simple fact of the matter is that the Earth takes a finite period of time to circle the Sun and return to the exact same single plane (if there is such a term) radial position, relative to the Sun and the Sun's own positional referencing. This period of time is called a "solar year".
Meanwhile, the Earth rotates at it's own speed and relative to it's own positional referencing. Each one of these revolutions is called a "day".
For whatever reason, a day was arbitrarily divided into 24 hours each of 60 minutes of 60 seconds. These divisions were not necessarily for the purpose of measuring time so much, as describing an angle. The earliest clocks were quite often just sticks in the ground. Relative. local time was approximated (or calculated) by the length of shadow.
Meanwhile, back to the Earth's journey around the Sun. Because of the Laws of Math and Physics, the plane of the tangent of the line between the centre of the Earth and the centre of the Sun would constantly change on a daily basis. But it was a sequence that repeated itself every solar year. This was noticeable in manner to the prominent sentient population of Earth. They called the phenomena "seasons".
For whatever reasons, it was decided to split the year into 12 segments which were, essentially, recognised by the position of various astral patterns or astrological star signs, if you will. These periods became known as months. It has been postulated that this is because of the factorial quality of 12, when used with all the other numbers in the "great circle" of progress, so to speak.
As civilization expanded and improved, the measurement of time and seasons became more important. Especially when people stopped moving around, feeding from hand to mouth, and settled down to build cities and grown food. A stick in the ground was not an ideal time piece, and there would not always be a sun, and for half a day there could never be a sun. And that's before we start applying any latitude to the issue.
So mechanical methods were devised and improved to measure the passing of time.
Then it was discovered that the number of rotations of the Earth in a solar year, which was now very firmly a calendar year and had nothing to do with approximating the right milking cows' rotations, was actually a Float and not an Integer.
The resulting panic and argument among the intelligentsia caused the loss of between 10 and 13 days of productivity (depening on which country you were in - see HERE if you want to know more. I was surprised, especially about Greece and Turkey). When the general population realised that the Boss's response to lost production was a reduction in wages. More panic and argument ensured, this time among the working classes, which caused quite a few Boss's to lose the heads over it.
Anyway. It was desired to prevent history from repeating itself, after all 2 weeks production is 2 weeks production. So the differences and losses were weighed and measured, poked and prodded until it could be formulised.
Then along came counting machines, or computers if you will (there were millions of mechanical computers before there were analogue ones, let alone digital ones - a cam is a very specialised mechanical computer). These date and time formulas were intrusted into their care. Which is why we don't need to roll our own. It is why computers know when to change to BST or DST, or pop up a reminder to tell us it is Shrove bloody Tuesday because it's the day before Advent, which is the first pissing day of Lent. All of which is totally dependant on When The Fuck Easter is going to decide to put in an appearance this year.
Or give a shit about subtracting a day or a month because the formulae FUCKING work. Furthermore they continue to FUCKING work when you apply such abstract concepts as "last week" or "the end of the month". Because such abstracts are second nature to us physiologically and physiologically, as we have spend millions of years evolving and adapting to them. So much so that we have given it a special name: circadian rhythm
So yeah, I don't roll my own, there's no need. If I want last months invoice from the DB, I construct my query with SELECT.... WHERE ...DATESUB(month, 1, now()), if it is the most appropriate method, or create a Date Time Object in my code, calculate the new date and use that explicitly; if that is the more appropriate. And there are a lots of factors to take into consideration, when deciding what is appropriate. Least of which is the consideration "Is data stored as an integer, or as a string?" Or if I just want to find out where yesterday is relative to tomorrow, seconds will do. And if I just so happen to include a random smegging Leap Second in that time frame, I very much doubt I'll lose any sleep over it - probably would not even have noticed.
WARNING
:hanzo: edit applied. +10 Internets if you can spot it.
Admin
...nah, you make it way too easy.
Admin
However,
interval.secondsis computable given any two Gregorian dates, provided you have the timezone and DST information for those dates at hand. (And leap seconds, but that's really just a list of timestamps saved off somewhere.)This doesn't change the point, though:
NEVER REINVENT THE DATE/TME LIBRARY WHEEL!
Filed under: I hear that a copy of Calendrical Calculations makes a fantastic clue-by-four...
Admin
Depending on your definition of "exactly 28 days", this algorithm may fail if invoked during the extra hour created when switching from daylight saving ("summer") time to standard time.
Admin
Did you know that the ISO spec for time intervals gets this right? It lets you say exactly 28 days without implying anything about exactly how many seconds that is (because for a lot of uses, saying 28 days is actually what people mean) and if you really want a precise number of seconds (such as 2419200) then you say that instead.
In short, say what you really mean. Don't say a not-quite-accurate proxy for it.
Admin
Ok, one more attempt to kick this insane pedantry to death :smile:
There Is Only One Time, And That Time Shall Be UTC, (except for those who live in the UK and they may call it GMT, but for only for as long as it is the same temporal time as UTC)
UTC Does Not Need Such Artificial Constructs As BST or DSL. It Leaves Such Things For Its Supplicants To Worry About (or not). UTC Knows Where Its Towel Is At (temporally speaking).
UTC Accepts That Things Are Not Perfect (like leap seconds and stuff) And Seeks to Overcome Such Temptations Of The Flesh.
Admin
I have no idea. Hopefully none. But that probably depends on which calendar system the Israeli equivalent of the IRS uses.
Admin
It looks like it is the Gregorian calendar. Which is a sensible decision because using a lunar calendar with intercalated months is a little bit difficult.
Admin
Not TAI? Or UT1?
There's an entire task force of experts who think deeply and argue horrifically about this - even before the politicians start screwing around.
I just smile and nod, and let somebody else deal with it.
Time is confusing. Is it lunchtime yet?
Admin
"Time is an illusion. Lunchtime doubly so." - Douglas Adams
:thumbsup: :smile:
Admin
Holy fuck you're ignorant. So many errors and misconceptions in your little rant, I really can't be bothered.
Admin
You know what I hate?
My full retirement eligibility is reached in 2038. About a month AFTER the rollover. :frowning:
INB4: It mostly won't matter, but still...the panic that some WILL foist on IT workers at that time, like the Y2k
debaclesnorefest.Admin
I will probably be in my grave by then. If I am, I promise to spin for you.
According to my abusive understanding of Game Theory, combined with my bastardised use of ternary logic, you stand less chance of experiencing !PROFIT as a result of it.
Spoiler: :hanzo: edit warning
My sincere apologies @redwizard. I deliberately invoked a :hanzo: edit to insure a "one off error" in my reply to posts in this topic. Because: As much as I, in accordance with the general advice on the subject, dislike the of feeding :trollface: But there are times when it is very important to point out that: evidently, I am not the one standing here with my ignorance hanging out for everybody to see
To explain (about the !PROFIT): When it rolls over and spits out a -1 (the true ternary third state). You could get the fabled, 32 bit expression of the currency of your choice, pension cheque ; a normal cheque if it spits out a 1; or, and this is where you would be unlucky and !PROFIT, a 0, null() or nill.
Again @redwizard my apologies for abusing your very good post in this way, but the planets were aligned and in conjunction with the stars and sometimes you need a bit of English on your spin to hit the right target.
Edit (a few hours later): Huh? I'm sure I replied to @redwizard, the whole point and thrust of my "rant" was create a "one off error". Still, never mind. Now.....how does that mute feature work.....
Admin
Now, now, hold there. GMT is not the same temporal time as UTC. GMT is not a temporal time. GMT is an angular time. True, UTC never differs from it by more than 0.9 of the different-unit-that-both-call-a-second numerically.
So for our UKian friends, please, for $deity's sake, don't call the time GMT. It is UTC. You watches are not capable of reproducing the varialble-length second of mean time.
Beware. Pendantry likes to kick back.
Admin
That's why you need somebody like HOSS around to hog tie 'em
ROFLMA
Admin
TIL. Though it is definitely the common thing here to use “GMT” as the name of the local non-DST timezone. (WET would be more correct, but we don't want that for idiotic parochialism raisins.)
Admin
Just checked mine - was sure it was before 2038, but it's moved to May 2039.
Not that I'm unduly worried. I fully expect at least one of the following to happen
The UK government will up the pension age again making that calculation incorrect
They'll means test the entirety of the State Pension which means I won't get any anyway
I'll be retiring on, or before, May 2027 irregar<!-- do I look as if I care? -->less (unless the UK government screw me over on that one too) - I've planned on not getting much, if any state pension, and any I do get will be a bonus.
Admin
OMG, I was going to add to this (possible) change in "direction of topic", with pedantry and facts gleaned from the internet (I should point out that I did refresh my knowledge of UTC / GMT, because things change and I have been known to be wrong). That I would present with the confidence of the ignorant.
But then I thought. How sad my life must be. Because I recalled how modern mobile devices and their infallible connection to Google via the internet, have spoiled the tradition of a "good time" as defined by an evening down the pub, or a natter over coffer, or (perversely) a virtual "discussion" over a keyboard.
Admin
It's people like you wot cause unrest.
The Y2K is strong with this one.
Admin
Yeah, I have that effect on people. I'm always peeking over the top of the rut and thinking "...what if..."
Sometimes you fall flat on your face in the brown smelly stuff, sometimes your find pastures full of Anchor dairy cows, with the occasional patches of different, but similar, smelly brown stuff.
Either way, if you don't stray from your comfort zone, you don't grow. People that suffer from agoraphobia are never going to discover those green fields. I wonder if there is a word that it (agoraphobia) translates to in this reality?
Admin
That's all very well until you're writing code that needs to keep track of future appointments.
If you just blanket-convert everything to UTC on entry, and work with (relatively) nice pure UTC or, easier still, POSIX time (which, unlike UTC, guarantees that a day is always 86400 seconds), and convert back to local time on display: all it takes to throw a future appointment out of whack is a time zone rules change between appointment save and appointment retrieval, which could be as simple and likely as a DST rule change or as rare but horrid as a reassignment of the TZ in which the appointment is to be kept from UTC-12h to UTC+12h.
In general, appointments are not made for a fixed number of seconds from now; they're made for a specific local time at a specific place. So you really do need to store them as destination-local date and time, and you need to build your system to cope with the fact that the time interval between any two fixed appointments cannot, in general, be relied on to stay the same.
Admin
A TAI- or GPS-locked smart watch with Internet access should be able to track GMT to within the precision of TAI.
Admin
If any of my code is still running in 5000AD, I'm not sure if that is success or failure.
Admin
Succailure? Failcess?
Admin
To be completely pedantic, GMT is currently not official name for anything. However by its name and historically it meant what UT1 does now: angle of the Mean Sun along the equator as measured on the 0° meridian and expressed in 24 hours instead of 360° in full circle.
That's the problem. TAI does not track GMT. GMT is a mean solar time in Greenwich (by name; officially that time was renamed to UT1) and as such uses second which is 1/86400 of a day. On the other hand TAI uses second which is the duration of 9192631770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium 133 atom. Those seconds have different length and the length of the former is not constant. UTC is a time that follows TAI, but gets a leap second inserted or removed whenever it approaches difference of 0.9 s from UT1, which is current official name for what used to be called GMT.
Admin
No it doesn't. But there are frequently-updated online observations available (see the link I provided above) that tabulate the difference. So given a half decent CPU (as opposed to something limited to dividing an input clock by 32768), a GPS receiver and occasional Internet access, it should be possible to sync to TAI with high precision, then use regularly updated Earth-rotation observations to construct an NTP-style drift-adjusted timebase for GMT.
Given that GMT is a civil rather than a scientific time, and given that it and POSIX both agree that a day should always consist of 86400 seconds, this would actually not be a completely insane way to run the primary RTC on any system primarily used for business.
As i see it, leap seconds are a cheap hack introduced for the benefit of hardware for which needing to maintain a drift-adjusted civil timebase would be too much of a burden. Such hardware is decreasingly common. I would very much like to see a network of civil time NTP servers introduced in parallel with the existing network of UTC ones.
The less said about ill conceived compromises like the Google leap smear, the better.
Admin
I had a strange "bug" which involved add_months many years back. I'd been assigned debugging duties in an old web application with a PL/SQL back end that the company I'd joined had developed a few years back but the users had only now finally decided to actually test. One of the bug reports that came through said that a particular search page wasn't returning the results it should have. The "screenshot" I'd received though was lacking debug information which the other bug reports had included. Basically they'd turn on debug mode, run the page and save it to a HTML file along with a note saying what was wrong with it. They said it had no debug information since it was normally called as part of a daily batch process. My manager responded with some kind of technobabble about how it could be some kind of settings and they said they'd get some consultants to check that out.
Months later I was taken off of the debugging to work full time on the big new project while another programmer took over. Even more months later the big project fell apart after the company we were subcontracting for got greedy and decided to keep the project for themselves. Even more months later I was asked to resume helping with debugging and the other programmer sent me through some bug reports. One of them l was the same one from many months ago. There was nothing in the log section of the bug report about them checking with the consultants and it still didn't have any debug info.
So I told the other programmer who told the client, who finally sent through the page after it had been run in debug mode. The first line of the debugging info said that a particular parameter was set to 90. I looked for it in the code and it was being fed into an add_months value after being turned into a negative value. According to the documentation it would make the search ignore anything younger than a certain date. The units for the value were in months, but someone had thought it was days. It was ignoring everything that wasn't over 7.5 years old.