When dating goes too far
-
well, most of the new systems already support 64 bit timestamps. I wonder if humanity will be still around when those overflow ...
-
-
Calculation of dates is always complex, especially if it is based on counting the days since a certain date. I think it is not a very efficient method, since it will always reach to as many days as possible in the future. Perhaps it would be more indicated, knowing that a date is a thing that is repeated periodically, of using a formula of those that exist for this purpose. This is also based on these perpetual calendars that was once in the dietary. And also these artists who name you on what day corresponds a date appointed by an audience.I don't know if it's possible to solve the problem this way, it's just an idea.
http://gmmentalgym.blogspot.com/2011/03/day-of-week-for-any-date-revised.html?m=1#ndatebasicsRemember that leap years are those divisible by 4, except the entire centuries that are not divisible by 400. That is, 2000 was a leap year, but 1900 was not.
-
Y10K (Aka millennium bug). Many softwares use Julian Data calendar.
Today is 02.056.
First the year, after the Julian dateBelow an excerpt of my userid
theoutput:USER=JBCMF NAME= OWNER=IBMUSER CREATED=86.007
Created on Jan 7th, 1986
Edited: grammar
-
@lamarca Or is Y10K the deca-millennium bug?
Y10K (Aka millennium bug). Many softwares use Julian Data calendar.
I didn't mean for my last post to be taken too seriously. Note the date on RFC 2550.
-
And here I came expecting to find a juicy selection of Tinder horror-stories... Imagine my disappointment...
-
It never ceases to amaze and annoy me when idiots claim that Y2K was "wrong" because there was no disaster after all. My dad was involved in checking and fixing systems at his company and I knew many IT students at the time who were busy with it as well. It was a massive deal and - because IT nerds tend to be methodical and modest - it got (mostly) fixed because everyone did a good job!
-
-
-
@stardepp Something lost in translation?
Facebook will be closed for technical maintenance from 30 to 31 February. Many users will try to log in to Facebook during this time. But they will succeed, as the site has been closed for maintenance without first warning the users.
Help your friends - and share them.
-
-
:smiling_face_with_open_mouth_cold_sweat:
-
-
-
@mossman: in large part it was going to affect billing much more than infrastructure. GPS stuff was very rare. Databases would be out of whack, but mostly billing depends on them. It was a big deal, but not the end of times kind of deal it was being reported as.
-
@lamarca said in When dating goes too far:
@xyzzy We called Y2K at the work. By that time, Racf (access control) was the facility software, which uses Julian Date. Year=two digits
1999 โ 2000Is that right @kahukura?
You are on Sys1.Parmlib
z/OSRACF presently displays the date still as yy.ddd
-
@kahukura Did you have a hard time with Y2K?
Either the software Dev updates time & date in Julian date format or the resource will be not controlled by Racf.Thanks for the classic response. Short and clear
-
@lamarca I still do remember the immense efforts to switch Operating Systems to an Y2K ready version. Also a lot of COBOL programs needed to be revised (if the source was found) and recompiled. One led to another but Big Blue did a good job with their OS and so did an unnamed army of programmers.
RACF is asked if access to a resource is given. My assumption is, that from the time the SVC13 is called it determines the right actions to deal with the date format. I don't know if the RRW (Report Writer) translates the YYDDD to CCYYDDD but in case SORT is used to provide reports possibilities are plenty to convert back and forth.
-
@kahukura The OS part was managed for the Mvs guys. My job was to check the the comparability between Cobal and Racf. SVC13? May I ask the Racf version?
-
@lamarca When you have an ABEND you see the called SVC. Anything access is x13, space x37 and so on.
I checked on our latest version that is z/OS 2.4