Re: [Fwd: Re: date formats]
In 1281901727.14657.141.ca...@mckown5.johnmckown.net, on 08/15/2010 at 02:48 PM, John McKown joa...@swbell.net said: Believe it or not, our 20xx dates are encoded x'9A001' for 2000, Which would imply that you had to track down every program that did arithmetic on dates. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: [Fwd: Re: date formats]
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Monday, August 16, 2010 4:56 AM To: IBM-MAIN@bama.ua.edu Subject: Re: [Fwd: Re: date formats] In 1281901727.14657.141.ca...@mckown5.johnmckown.net, on 08/15/2010 at 02:48 PM, John McKown joa...@swbell.net said: Believe it or not, our 20xx dates are encoded x'9A001' for 2000, Which would imply that you had to track down every program that did arithmetic on dates. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Which we did. Every program was examined for Y2K. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-691-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: date formats
On Sun, 15 Aug 2010 20:01:49 -0500, Joel C. Ewing wrote: The point of Shmuel's comment, of course, is that the one most common, unavoidable-in-MVS place where dates of the form yyddd were in wide-scale use was in SMF accounting records. The format there is packed-decimal, so hex digits are out. The old format was actually +00yyddd, where the 00 was reserved, so the one and only way to preserve the packed decimal representation and also preserve the existing relationship that the representation for the next year is current year + 1 (in base 10) was to go with 2000-01-01 == 011, which is what IBM did. For those who were already converting SMF dates into a four-digit year via 00yyddd + 190, this extension was so compatible that it wasn't even necessary to make any code changes for Y2K! Thanks. I had been unfamiliar with the format of SMF data. Which still leaves me wondering why, if they used 4-byte packed decimal, they didn't from the very beginning place the century ratner than 00 in the left byte, making the conversion to a 4-digit year even simpler by one addition? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date formats
zMan wrote: On Fri, Aug 13, 2010 at 12:29 PM, Brian Kennelly brian+ibm-m...@bkennelly.net wrote, re days so far in the year as a date format: That is actually a very import format, as well as the full format returned by the TIME macro: 0cyyddd. (Century, year, days in year.) Sure, days this year can be useful, but does anyone store dates as days so far in the year? It's basically the Julian date without the year. Nomad's internal date format is number of days since 1600/01/01. Rolls over in a few thousand years. Lloyd -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date formats
In aanlktinywtvwhvqwd8ogoog2kkotyyis40s9taxbj...@mail.gmail.com, on 08/13/2010 at 12:25 PM, zMan zedgarhoo...@gmail.com said: How many different date formats are there? How many would you like? Are you only concerned with the Gregorian calendar? There's the hardware timestamp, With your choice of epoch. There's some UNIX format that rolls over in 2034 Only on 32-bit systems. Not to mention yy/mm/dd, mm/dd/yy, dd/mm/yy, Or month given in letters, abbreviated or in full. English or local language. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: date formats
In listserv%201008131709378676.0...@bama.ua.edu, on 08/13/2010 at 05:09 PM, Paul Gilmartin paulgboul...@aim.com said: I'll agree enthusiastically except where the change could be made in a compatible manner, altering no sizes, displacements, nor content of existing data bases. One example might be that where Dec. 31, 1999 is represented as x'99365', Jan. 1, 2000 could (have) been represented as x'A0001' That would not have been compatible. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: date formats
On Sun, 2010-08-15 at 08:23 -0400, Shmuel Metz (Seymour J.) wrote: In listserv%201008131709378676.0...@bama.ua.edu, on 08/13/2010 at 05:09 PM, Paul Gilmartin paulgboul...@aim.com said: I'll agree enthusiastically except where the change could be made in a compatible manner, altering no sizes, displacements, nor content of existing data bases. One example might be that where Dec. 31, 1999 is represented as x'99365', Jan. 1, 2000 could (have) been represented as x'A0001' That would not have been compatible. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
[Fwd: Re: date formats]
Forwarded Message From: John McKown joa...@swbell.net Subject: Re: date formats Date: Sun, 15 Aug 2010 13:27:39 -0500 On Sun, 2010-08-15 at 08:23 -0400, Shmuel Metz (Seymour J.) wrote: In listserv%201008131709378676.0...@bama.ua.edu, on 08/13/2010 at 05:09 PM, Paul Gilmartin paulgboul...@aim.com said: I'll agree enthusiastically except where the change could be made in a compatible manner, altering no sizes, displacements, nor content of existing data bases. One example might be that where Dec. 31, 1999 is represented as x'99365', Jan. 1, 2000 could (have) been represented as x'A0001' That would not have been compatible. Believe it or not, our 20xx dates are encoded x'9A001' for 2000, and so on up the alphabet. I wasn't in on this, so I don't know where it terminates. But x'9F' is the max - 2015. So the world better end in 2012! grin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: date formats
On Sun, 15 Aug 2010 08:23:18 -0400, Shmuel Metz (Seymour J.) wrote: In listserv%201008131709378676.0...@bama.ua.edu, on 08/13/2010 at 05:09 PM, Paul Gilmartin said: I'll agree enthusiastically except where the change could be made in a compatible manner, altering no sizes, displacements, nor content of existing data bases. One example might be that where Dec. 31, 1999 is represented as x'99365', Jan. 1, 2000 could (have) been represented as x'A0001' That would not have been compatible. Well, yes. The entire 21st century is intrinsically incompatible with software incapable of formatting dates past 1999. I merely suggested that bit patterns previously deemed invalid could be used (as a stopgap, I failed to say) to encode a further range of dates until necessary changes in data formats can be made. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: [Fwd: Re: date formats]
On Sun, Aug 15, 2010 at 2:48 PM, John McKown joa...@swbell.net wrote: Believe it or not, our 20xx dates are encoded x'9A001' for 2000, and so on up the alphabet. I wasn't in on this, so I don't know where it terminates. But x'9F' is the max - 2015. So the world better end in 2012! grin x'90' 1990 x'9a' 2000 x'9f' 2005 x'a0' 2006 x'aa' 2016 x'af' 2021 x'b0' 2022 x'ba' 2032 x'bf' 2037 x'c0' 2038 x'ca' 2048 x'cf' 2053 x'd0' 2054 x'da' 2064 x'df' 2069 x'e0' 2070 x'ea' 2080 x'ef' 2085 x'f0' 2086 x'fa' 2096 x'ff' 2100 At some point, dump the 20th century data and use 2000 as the base instead of 1900 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: date formats
On 08/15/2010 03:07 PM, Paul Gilmartin wrote: On Sun, 15 Aug 2010 08:23:18 -0400, Shmuel Metz (Seymour J.) wrote: In listserv%201008131709378676.0...@bama.ua.edu, on 08/13/2010 at 05:09 PM, Paul Gilmartin said: I'll agree enthusiastically except where the change could be made in a compatible manner, altering no sizes, displacements, nor content of existing data bases. One example might be that where Dec. 31, 1999 is represented as x'99365', Jan. 1, 2000 could (have) been represented as x'A0001' That would not have been compatible. Well, yes. The entire 21st century is intrinsically incompatible with software incapable of formatting dates past 1999. I merely suggested that bit patterns previously deemed invalid could be used (as a stopgap, I failed to say) to encode a further range of dates until necessary changes in data formats can be made. -- gil The point of Shmuel's comment, of course, is that the one most common, unavoidable-in-MVS place where dates of the form yyddd were in wide-scale use was in SMF accounting records. The format there is packed-decimal, so hex digits are out. The old format was actually +00yyddd, where the 00 was reserved, so the one and only way to preserve the packed decimal representation and also preserve the existing relationship that the representation for the next year is current year + 1 (in base 10) was to go with 2000-01-01 == 011, which is what IBM did. For those who were already converting SMF dates into a four-digit year via 00yyddd + 190, this extension was so compatible that it wasn't even necessary to make any code changes for Y2K! Granted, if you had existing databases or files with 3-byte-decimal or 5-character YYDDD dates, you had a much more serious problem. Any way you went, using-unused bits, expanding the field, at some instant the field definition would change and all code touching that field had to be revised accordingly. Except for separate interpretation rules for older archived data, it always made sense to us that if you had to change a field and all related programs it was best to stick with simpler representations that avoided future headaches. If a larger field was unacceptable, a 3-byte integer Lilian date is much simpler to work with in the long run than having different bit-twiddling rules for different digits of the year. The original question raised of what date formats should be supported by a conversion routine has a different answer if the object is to support a single installation rather than for a general purpose vendor utility. It makes sense that local installation standards should try to minimize the number of different date representations used locally to minimize confusion and needless conversions. -- Joel C. Ewing, Fort Smith, ARjcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date formats
What about NETTIME used by NTP (and friends). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date formats
You forgot SMF time: number of hundredths of seconds since midnight. Jon L. Veilleux veilleu...@aetna.com (860) 636-9179 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of zMan Sent: Friday, August 13, 2010 12:25 PM To: IBM-MAIN@bama.ua.edu Subject: Date formats How many different date formats are there? There's the hardware timestamp, in two forms (original, with the 2046 rollover, and the extended one -- what is that, a STCKE instruction?). There's something called an Oracle format date. There's some UNIX format that rolls over in 2034 or some such (tsk, with an epoch of 1970 -- they sure weren't planning ahead!), too. Not to mention yy/mm/dd, mm/dd/yy, dd/mm/yy, with 2- and 4-digit dates, varying separators (or no separators: mmdd et al.), with and without leading zeroes (when there are separators: today as 8/13/2010 vs. 08/13/2010). And of course (the misnamed) Julian format. Rexx has a few others, but they're conveniences, like the number of days this year -- I don't really consider that a date format, though it's useful sometimes. What others are there? I'm working on something that will flexibly handle dates, and while I'm not sure I'll handle every format possible, I'd at least like to make the decision based on a pretty complete set of possible formats. -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date formats
On Fri, Aug 13, 2010 at 09:25, zMan zedgarhoo...@gmail.com wrote: Rexx has a few others, but they're conveniences, like the number of days this year -- I don't really consider that a date format, though it's useful sometimes. That is actually a very import format, as well as the full format returned by the TIME macro: 0cyyddd. (Century, year, days in year.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date formats
There are two that I know of which you did not mention. Lilian and COBOL. COBOL is an integer which is the number of days since 31Dec1600. Lilian is an integer which is the number of days since 14Oct1582. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . (817)-691-6183 cell john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of zMan Sent: Friday, August 13, 2010 11:25 AM To: IBM-MAIN@bama.ua.edu Subject: Date formats How many different date formats are there? There's the hardware timestamp, in two forms (original, with the 2046 rollover, and the extended one -- what is that, a STCKE instruction?). There's something called an Oracle format date. There's some UNIX format that rolls over in 2034 or some such (tsk, with an epoch of 1970 -- they sure weren't planning ahead!), too. Not to mention yy/mm/dd, mm/dd/yy, dd/mm/yy, with 2- and 4-digit dates, varying separators (or no separators: mmdd et al.), with and without leading zeroes (when there are separators: today as 8/13/2010 vs. 08/13/2010). And of course (the misnamed) Julian format. Rexx has a few others, but they're conveniences, like the number of days this year -- I don't really consider that a date format, though it's useful sometimes. What others are there? I'm working on something that will flexibly handle dates, and while I'm not sure I'll handle every format possible, I'd at least like to make the decision based on a pretty complete set of possible formats. -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date formats
Having grown up using dd/mm/yy then having to switch to mm/dd/yy so I don't know whether my birthday is 09/06 or 06/09 I'm partial to a ddmmmyy format where mmm is JAN, FEB, ... DEC Alan -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of zMan Sent: Friday, August 13, 2010 11:25 To: IBM-MAIN@bama.ua.edu Subject: Date formats How many different date formats are there? There's the hardware timestamp, in two forms (original, with the 2046 rollover, and the extended one -- what is that, a STCKE instruction?). There's something called an Oracle format date. There's some UNIX format that rolls over in 2034 or some such (tsk, with an epoch of 1970 -- they sure weren't planning ahead!), too. Not to mention yy/mm/dd, mm/dd/yy, dd/mm/yy, with 2- and 4-digit dates, varying separators (or no separators: mmdd et al.), with and without leading zeroes (when there are separators: today as 8/13/2010 vs. 08/13/2010). And of course (the misnamed) Julian format. Rexx has a few others, but they're conveniences, like the number of days this year -- I don't really consider that a date format, though it's useful sometimes. What others are there? I'm working on something that will flexibly handle dates, and while I'm not sure I'll handle every format possible, I'd at least like to make the decision based on a pretty complete set of possible formats. -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date formats
The International Astronomical Union uses the Julian Date / Time format. 0 was at January 1, 4713 BCE Greenwich noon, increments by 1 per day, decimal fraction of day for time. http://en.wikipedia.org/wiki/Julian_day Various Gregorian calendar formats, including a list by country. http://en.wikipedia.org/wiki/Calendar_date Displays a date in various calendar formats. Links to many explanations of various Calendars. http://www.calendarhome.com/converter/ On Fri, Aug 13, 2010 at 11:32 AM, McKown, John john.mck...@healthmarkets.com wrote: There are two that I know of which you did not mention. Lilian and COBOL. COBOL is an integer which is the number of days since 31Dec1600. Lilian is an integer which is the number of days since 14Oct1582. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . (817)-691-6183 cell john.mck...@healthmarkets.com . www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of zMan Sent: Friday, August 13, 2010 11:25 AM To: IBM-MAIN@bama.ua.edu Subject: Date formats How many different date formats are there? There's the hardware timestamp, in two forms (original, with the 2046 rollover, and the extended one -- what is that, a STCKE instruction?). There's something called an Oracle format date. There's some UNIX format that rolls over in 2034 or some such (tsk, with an epoch of 1970 -- they sure weren't planning ahead!), too. Not to mention yy/mm/dd, mm/dd/yy, dd/mm/yy, with 2- and 4-digit dates, varying separators (or no separators: mmdd et al.), with and without leading zeroes (when there are separators: today as 8/13/2010 vs. 08/13/2010). And of course (the misnamed) Julian format. Rexx has a few others, but they're conveniences, like the number of days this year -- I don't really consider that a date format, though it's useful sometimes. What others are there? I'm working on something that will flexibly handle dates, and while I'm not sure I'll handle every format possible, I'd at least like to make the decision based on a pretty complete set of possible formats. -- zMan -- I've got a mainframe and I'm not afraid to use it -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date formats
On Fri, Aug 13, 2010 at 12:29 PM, Brian Kennelly brian+ibm-m...@bkennelly.net wrote, re days so far in the year as a date format: That is actually a very import format, as well as the full format returned by the TIME macro: 0cyyddd. (Century, year, days in year.) Sure, days this year can be useful, but does anyone store dates as days so far in the year? It's basically the Julian date without the year. Thanks re TIME format -- also important. Tho again, that's kind of just Julian with some noise on the front... -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date formats
On Fri, Aug 13, 2010 at 12:32 PM, McKown, John john.mck...@healthmarkets.com wrote: There are two that I know of which you did not mention. Lilian and COBOL. COBOL is an integer which is the number of days since 31Dec1600. Lilian is an integer which is the number of days since 14Oct1582. Wow, in 35 years I've never heard of either! But then, I'm not a COBOL maven. Thanks. -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date formats
On Fri, Aug 13, 2010 at 10:42, zMan zedgarhoo...@gmail.com wrote: Sure, days this year can be useful, but does anyone store dates as days so far in the year? It's basically the Julian date without the year. Yes, they do. I worked on a data conversion product a few years ago for a software vendor, and that was one of the formats we needed to support, on multiple sites. Yes, it was more often Julian format, but many customers stored the year and days separately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date formats
SAS uses lots of date formats. ISO 8601 is a good spot to look for a large list. http://support.sas.com/documentation/cdl/en/lrdict/63026/HTML/default/a003169814.htm http://en.wikipedia.org/wiki/ISO_8601 zMan wrote: How many different date formats are there? There's the hardware timestamp, in two forms (original, with the 2046 rollover, and the extended one -- what is that, a STCKE instruction?). There's something called an Oracle format date. There's some UNIX format that rolls over in 2034 or some such (tsk, with an epoch of 1970 -- they sure weren't planning ahead!), too. Not to mention yy/mm/dd, mm/dd/yy, dd/mm/yy, with 2- and 4-digit dates, varying separators (or no separators: mmdd et al.), with and without leading zeroes (when there are separators: today as 8/13/2010 vs. 08/13/2010). And of course (the misnamed) Julian format. Rexx has a few others, but they're conveniences, like the number of days this year -- I don't really consider that a date format, though it's useful sometimes. What others are there? I'm working on something that will flexibly handle dates, and while I'm not sure I'll handle every format possible, I'd at least like to make the decision based on a pretty complete set of possible formats. -- zMan -- I've got a mainframe and I'm not afraid to use it -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date formats
SAS uses lots of date formats. ISO 8601 is a good spot to look for a large list. Now, you have to be careful about that statement! SAS displays a lot of formats. But, usually, there is only one internal format. Days from June 1, 1960, iirc. - I'm a SuperHero with neither powers, nor motivation! Kimota! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date formats
Years ago, Dr Merrill stated that MXG probably processed more different date and time formats than any other software package. If you have access to it, it may provide a good starting point. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of zMan Sent: Friday, August 13, 2010 9:25 AM To: IBM-MAIN@bama.ua.edu Subject: Date formats How many different date formats are there? There's the hardware timestamp, in two forms (original, with the 2046 rollover, and the extended one -- what is that, a STCKE instruction?). There's something called an Oracle format date. There's some UNIX format that rolls over in 2034 or some such (tsk, with an epoch of 1970 -- they sure weren't planning ahead!), too. Not to mention yy/mm/dd, mm/dd/yy, dd/mm/yy, with 2- and 4-digit dates, varying separators (or no separators: mmdd et al.), with and without leading zeroes (when there are separators: today as 8/13/2010 vs. 08/13/2010). And of course (the misnamed) Julian format. Rexx has a few others, but they're conveniences, like the number of days this year -- I don't really consider that a date format, though it's useful sometimes. What others are there? I'm working on something that will flexibly handle dates, and while I'm not sure I'll handle every format possible, I'd at least like to make the decision based on a pretty complete set of possible formats. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date formats
Years ago, Dr Merrill stated that MXG probably processed more different date and time formats than any other software package. MXG had that facilty mainly because SAS could do most of them. But, once read, they were stored in internal (SAS) format. Don't get me wrong. MXG is a great example of software enginering. - I'm a SuperHero with neither powers, nor motivation! Kimota! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: date formats
Formats are of interest for displaying|printing dates. They are of almost no interest for storing dates, which should be stored as signed integers that specify day counts before and after some epoch origin, giving each day a serial number in the sequence . . . , -2, -1, 0, +1, +2, . . . The obvious epoch origin to use is that for CE and BCE dates, viz., December 31 of the Gregorian calendar. Other epoch origins can then be supported simply using a table of displacements. Thus, for example, +622 July 19 is the Gregorian date of the epoch origin of the Islamic religious calendar, and one converts a Gregorian day G into an Islamic one H by subtracting 227,015, the Gregorian serial number of this date, from G. Or again, a Julian astronomical day J is obtained from a Gregorian day G by subtracting -1,721,424, the G of -4713 November 24, the epoch origin of the Julian astronomical calendar. Storing multiple date formats is a mug's game. It brings the need for too many conversion routines in train. The canonical reference for all calendrical calculations, which I have mentioned on IBM-MAIN before, is Nachum Dershowitz Edward M. Reingold. Calendrical computations. Cambridge: Cambridge University Press, 1997. Practices different from the one I have just summarized very briefly are common, but they are indefensible. They are always parochial, different in different milieux and for different natural languages; and they reflect a fatal confusion between external display formats, appropriate for people, and internal arithmetic formats, appropriate for calendrical computations performed by computers. John Gilmore Ashland, MA 01721-1817 USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date formats
On Fri, 13 Aug 2010 12:25:01 -0400, zMan wrote: How many different date formats are there? There's the hardware timestamp, in two forms (original, with the 2046 rollover, and the extended one -- what is that, a STCKE instruction?). There's something ETOD ends at the same point as TOD, despite having an unused high order byte. called an Oracle format date. There's some UNIX format that rolls over in 2034 or some such (tsk, with an epoch of 1970 -- they sure weren't planning ahead!), too. dec's OS 8 used 3 bits for the year. Ended in 1978. Not to mention yy/mm/dd, mm/dd/yy, dd/mm/yy, with 2- and 4-digit dates, varying separators (or no separators: mmdd et al.), with and without leading zeroes (when there are separators: today as 8/13/2010 vs. 08/13/2010). And of course (the misnamed) Julian format. Jewish? Moslem? Chinese? I understand the official Japanese calendar numbers years relative to the beginning of the current emperor's reign. http://en.wikipedia.org/wiki/Japanese_era -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: date formats
On Fri, 13 Aug 2010 18:48:55 +, john gilmore wrote: The obvious epoch origin to use is that for CE and BCE dates, viz., December 31 of the Gregorian calendar. Other epoch origins can then be supported simply using a table of displacements. That would be a proleptic Gregorian calendar? Practices different from the one I have just summarized very briefly are common, but they are indefensible. E.g. ISPF's storing PDS member dates in a display-oriented format. Local time or Greenwich time? Sooner or later, the variability in the earth's rotation will matter. UTC is already 34 seconds behind TAI. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: date formats
john gilmore wrote: Formats are of interest for displaying|printing dates. They are of almost no interest for storing dates, which should be stored as signed integers that specify day counts before and after some epoch origin, giving each day a serial number in the sequence Oh my! Should be? Is there some intrinsic universal factor that makes it so? Are all those who choose some different format (many interesting ones have been pointed out already) somehow wrong because they choose a format that works for them in their business needs? One of my very first customers was a savings and loan in Albuquerque that stored mortgate payment dates as positive numbers if the payment had been made and negative dates if the payment had not yet come in. Worked for them. == . . . , -2, -1, 0, +1, +2, . . . The obvious epoch origin to use is that for CE and BCE dates, viz., December 31 of the Gregorian calendar. Other epoch origins can then be supported simply using a table of displacements. Thus, for example, +622 July 19 is the Gregorian date of the epoch origin of the Islamic religious calendar, and one converts a Gregorian day G into an Islamic one H by subtracting 227,015, the Gregorian serial number of this date, from G. Or again, a Julian astronomical day J is obtained from a Gregorian day G by subtracting -1,721,424, the G of -4713 November 24, the epoch origin of the Julian astronomical calendar. Storing multiple date formats is a mug's game. It brings the need for too many conversion routines in train. The canonical reference for all calendrical calculations, which I have mentioned on IBM-MAIN before, is Nachum Dershowitz Edward M. Reingold. Calendrical computations. Cambridge: Cambridge University Press, 1997. Practices different from the one I have just summarized very briefly are common, but they are indefensible. They are always parochial, different in different milieux and for different natural languages; and they reflect a fatal confusion between external display formats, appropriate for people, and internal arithmetic formats, appropriate for calendrical computations performed by computers. Pompous nonsense! I find the varieties of storing dates fascinating, and each one has been chosen for a reason that met some need. Yes, parochial to some degree. But practical for the moment. Even with your approach there are choices to make: is there a largest and / or smallest bound? from an astronomical perspective, choosing Earth days is totally parochial. Even the duration of these changes over time. :-) John Gilmore Ashland, MA 01721-1817 USA -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date formats
Don Poitras wrote: SAS uses lots of date formats. ISO 8601 is a good spot to look for a large list. http://support.sas.com/documentation/cdl/en/lrdict/63026/HTML/default/a003169814.htm http://en.wikipedia.org/wiki/ISO_8601 zMan wrote: How many different date formats are there? There's the hardware timestamp, in two forms (original, with the 2046 rollover, and the extended one -- what is that, a STCKE instruction?). There's something called an Oracle format date. There's some UNIX format that rolls over in 2034 or some such (tsk, with an epoch of 1970 -- they sure weren't planning ahead!), too. Not to mention yy/mm/dd, mm/dd/yy, dd/mm/yy, with 2- and 4-digit dates, varying separators (or no separators: mmdd et al.), with and without leading zeroes (when there are separators: today as 8/13/2010 vs. 08/13/2010). And of course (the misnamed) Julian format. Rexx has a few others, but they're conveniences, like the number of days this year -- I don't really consider that a date format, though it's useful sometimes. What others are there? I'm working on something that will flexibly handle dates, and while I'm not sure I'll handle every format possible, I'd at least like to make the decision based on a pretty complete set of possible formats. -- zMan -- I've got a mainframe and I'm not afraid to use it DFSORT supports a large variety of stored date formats, presumably SyncSort does too. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: date formats
Paul Gilmartin wrote: | That would be a proleptic Gregorian date? and the answer to his question is that the dates of all days that occur before a calendar's epoch origin are proleptic for that calendar by definition. Their day numbers are negative. The use of a fullword for Gregorian day values provides the capacity for specifying dates about 10 million years before and after the Gregorian epoch origin, December 31 or 0001 January 1, depending upon one's preference for zero-origin or one-origin subscripting and the like. Whether such dates are common or uncommon depends on context. Payroll systems do not deal in them; egyptologists do;. and I recently read a new biography of Alexander the Great (Alexander III of Macedon) that---except for its title page, copyright notice, and bibliography---deals only in proleptic dates: he was born in 356 BCE and died in 323 BCE. One of the most dispiriting things about the money and time that were spent on Y2K remediation is that it was almost all done very badly: all the old data representations, their calendar-arithmetic deficiencies, and the errors they give rise to were lovingly preserved. John Gilmore -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: date formats
On Fri, 13 Aug 2010 21:49:19 +, john gilmore wrote: | That would be a proleptic Gregorian date? and the answer to his question is that the dates of all days that occur before a calendar's epoch origin are proleptic for that calendar by definition. Their day numbers are negative. The use of a fullword for Gregorian day values provides the capacity for specifying dates about 10 million years before and after the Gregorian epoch origin, December 31 or 0001 January 1, depending upon one's preference for zero-origin or one-origin subscripting and the like. I was more thinking of 1582. Wikipedia (which is always right except when it disagrees with you) says: http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar The proleptic Gregorian calendar is produced by extending the Gregorian calendar backward to dates preceding its official introduction in 1582. One of the most dispiriting things about the money and time that were spent on Y2K remediation is that it was almost all done very badly: all the old data representations, their calendar-arithmetic deficiencies, and the errors they give rise to were lovingly preserved. I'll agree enthusiastically except where the change could be made in a compatible manner, altering no sizes, displacements, nor content of existing data bases. One example might be that where Dec. 31, 1999 is represented as x'99365', Jan. 1, 2000 could (have) been represented as x'A0001' in a field of the same size and sorting in a consistent order. Or am I inviting the documented y2.01k glitch? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date formats
On 08/13/2010 12:43 PM, zMan wrote: On Fri, Aug 13, 2010 at 12:32 PM, McKown, John john.mck...@healthmarkets.com wrote: There are two that I know of which you did not mention. Lilian and COBOL. COBOL is an integer which is the number of days since 31Dec1600. Lilian is an integer which is the number of days since 14Oct1582. Wow, in 35 years I've never heard of either! But then, I'm not a COBOL maven. Thanks. The origin of the Lilian date terminology has nothing to do with COBOL. It was proposed in 1986 by Bruce Ohms in Computer processing of dates outside the twentieth century. IBM Systems Journal (IBM) 25: 244–251, as part of the solution to the coming Y2K problem. The peculiar starting date is the date the Gregorian calendar went into effect (for countries subject to the Pope). We had a widely used installation date routine that pre-dated my arrival in 1978 that did some date conversions and date manipulation, but the user interfaces, code, and algorithms used were so unstructured that that it was next to impossible to have any assurance it would, or could even be made to, work across the Y2K boundary. The Ohms article inspired me to design a totally new date/time routine from the ground up that replaced the old in the early 1990's and became one of the building blocks for our Y2K effort, with Lilian dates being one of the date forms supported. It supported n different input and output date/time format variants, where n was on the order of 20, but avoided the need for n(n-1) different conversion routines by having many conversions go through multiple date/time formats internally before reaching the target form (analogous to routing network packets through intermediary nodes). Date adjustments would be done internally after first converting the date into a format most natural for the adjustment (e.g. Lilian for relative day offsets and day-ordinal-of-week dependencies, MMDD for day of month or relative month adjustments, etc.) and then the internal value would be converted to the desired target form. The COBOL relative day support didn't become available until long after we had already laid the ground work for Y2K remediation, and while it provided a building block that can be a basis for a generalized date conversion solution and date calculation, it was only a tool, not a complete solution. I believe LE runtime library now provides very flexible date conversion, but date/time adjustments, like returning 2nd Sunday of the month containing this date, MMDD + 5 days - MMDD, or current date/time + 8 hours still require roll-your-own effort, while our routine handles this kind of thing with a single call. -- Joel C. Ewing, Fort Smith, ARjcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: date formats
On Fri, Aug 13, 2010 at 5:09 PM, Paul Gilmartin paulgboul...@aim.com wrote: deleted I was more thinking of 1582. Wikipedia (which is always right except when it disagrees with you) says: http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar The proleptic Gregorian calendar is produced by extending the Gregorian calendar backward to dates preceding its official introduction in 1582. deleted -- gil The Julian Calendar was still in use in Greece at the time of the 1896 Olympics, and the 12 day discrepancy caused problems with visas and passports. The Orthodox churches (Greek, Russian, etc) still use the Julian calendar for holidays so their Christmas falls 13 days later than the Gregorian Christmas. http://www.tondering.dk/claus/cal/node3.html#SECTION00324000 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
