× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Dates, times, and timestamps are stored the same way whether table/file created DDS source or by a CREATE TABLE. The underlying objects and data types are the same. That is what object-based system is all about.

The internal length of a date is 4 bytes - it's probably a serial number representing a number of days from some starting point - someone it is a Lillian date - I'm not sure, but it might be - that's after some day in 1400 something, as I recall.

A time is 3 bytes long internally

A timestamp (7.1 and before) is 10 bytes long - that is a date (4) a time(3) and microseconds (3 more). In 7.2 we can have up to 12 "micro" digits, so maybe the length is increased - I'm on 7.1 and can't see that.

I did a hex(tdate) and hex(ttime) and hex(ttimestamp) and the results are 8 long for dates - that's 4 bytes - time is 6 long and looks like hours-minutes-seconds stored in nybbles - 10:15:35 would be x'101535' - I don't know that for certain, just surmising some stuff. Timestamp is 20 hex digits, the last 6 would be the microseconds stored in nybbles again, perhaps. So here is the result of displaying both the values and the hex contents of a date field, a time field, and a timestamp field

HEX ( TDATE ) TDATE HEX ( TTIME ) TTIME HEX ( TTMSTMP ) TTMSTMP
00257EDA 10/10/15 111213 11:12:13 00257EDA111213123456 2015-10-10-11.12.13.123456

Note the TDATE value is displayed in the job's DATFMT - presentation is managed at application level - storage is always the same.

Actually I think the date number is the number of days since January 1, 4713 BCE - this was established by a certain Scaliger, as a date when several calendars coincided. We've had a discussion in these lists about what is what in regard to Julian and other calendar naming - I won't get into what I don't remember.

If I take the number of days above (x'257EDA', decimal 2,457,306 and divide by 365.25 and subtract 4713 from that number, I get 2014.7

And __remember___ - it doesn't matter how the table was created - all date/time values are stored the same in the underlying physical storage.

HTH
Vern

On 10/16/2015 4:29 PM, Matt Olson wrote:
I'm assuming your talking about database column dates.

As far as I know DB2 stores the date in ISO format if the file is described with DDL (SQL).

If it is described using DDS all bets are off as you could define the date format at creation, so there is no real standard there, could be *USA, *ISO, etc.

So it depends on how the file was described.


-----Original Message-----
From: Justin Dearing [mailto:zippy1981@xxxxxxxxx]
Sent: Friday, October 16, 2015 4:08 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Is there a name for date format used by DB2?

Its not ISO 8601. does it adhere to a published standard, or is it an IBM standard?

Yes, its a bit of pedantry. However, I want to patch the DateTime object in PHP, and possible python, and it would be an easier sell to get my patch accepted into the core dateTime objecct for an OS if I was supporting some ANSI/ISO standard as opposed to "the format the IBM i uses".

Justin
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.