What is the maximum date for LVM file system with 64bit 11i?

[Geoff Wild]

Under 32 bit, Unix max date is sometime in 2038...What about 64 bit? and does that affect the file system level?

Points to online doc get preference.

Rgds...Geoff

[Robert-Jan Goossens · Accepted solution]

Hi Geoff,

Believe it is the same.

http://www.docs.hp.com/hpux/pdf/B2355-90782docs.pdf
---
HP-UX 11i Version 2: August 2003
day_of_year specifies the day of the year in the form month/day/year in the format:
mm/dd/[yy]yy. Specify month and day numerically, using one or two digits. For
example, January can be specified as 1 or 01; the third day of the month as 3 or
03. Specify the year in four digits or by its last two digits. Only years in the ranges
1970-2037 are accepted. Two digit years in the range 70-99 are interpreted as
being in the 20th century (19xx) and those in the range 00-37 are interpreted as
being in the 21st century (20xx) (all ranges inclusive). day_of_year is an optional
field; the current date is used as a default.
---

Regards,
Robert-Jan

[Simon Hargrave]

The latest date that "touch" lets me do on a 46 bit file is: -

19th January 2038, 03:14am. Any later and it balks ;)

touch 203801190314 testfile

[Fabio Ettore]

Hi Geoff,

why do you think that it depends from O.S. versions/bits?

Anyway what do you mean with 'Under 32 bit, Unix max date is sometime in 2038'?
Do you see date larger than 2038?
I never saw date larger than 2038.
I have a HP-UX 11i 64bit system and 2038 is largest date too.

However I think that Rob's indication is the best document.

Sorry my questions, just to clarify the thread.

Best regards,
Ettore

[Geoff Wild]

Yes - I know Jan 18, 2038 is farthest I can go - to me that tell's me that even though the OS is 64 Bit's, the file system isn't. A programmer here was asking why.

I found this doc on the net:

http://www.ibiblio.org/team/history/2000/mirrors/WW61.html

"For the INTERACTIVE UNIX System, a program is deemed y2000 Compliant' if it accurately and unambiguously accepts, stores, manipulates and displays dates within the range 00:00:00 January 1 1970 to 03:14:07 January 19 2038, as detailed in this document.

You will note that the date range specified above is a subset of the possible date range that may be stored in a type time_t. This statement is designed to fall in line with existing standards (IEEE 1003.1[1] and XPG3[2]) and the draft recommendation on Millennium Rollover from X/Open[3]. For a statement on the use of dates before 00:00:00 January 1 1970 (negative values of time_t), see Appendix I.

Note that this document does not address the extension of the maximum representable date, 03:14:07 January 19 2038, inherent in the 32 bit time_t data type. The INTERACTIVE UNIX System time_t type will remain a 32 bit value. Customers with an immediate need for date manipulation beyond 2038 may wish to contact their sales representative and discuss migration to a version of Solaris that uses a 64 bit time type. "

Rgds...Geoff

[Hein van den Heuvel]

Geoff,

The definition of the date field is an entirely independend choice from the number of bits the system/cpu does its work in.

For example, HP's OpenVMS has had a 64 bit binary date form day 1. It was born well over 25 years ago at Digital as VMS, on a 32 bit VAX, when that company was mostly 16 bit (PDP-11) and not thinkig in 64-bit computing terms at all. The OpenVMS date will be good for milleniums to come while also allowing for the birthday of any living person to be recorded in binary system time format.


Filesystems can and will select a date representation different from the binary system time, but Hpux did not do this best I know.

The Tru64 AdvFS (coming to hpux 'real soon now'!) implementation has taken some steps already to allow for 64 bit time.
For example the stat-structure has reserved fields, garantueed to be zero for now, which on a little endian machine smoothly extent the 32 bit value in to 64 bit without breaking existing programs. The on disk structure there use timval with sec and usec fields. There is some thought to exploit unsed Usec bit (a few high ones, several low ones) to encode 64 bit date values in a hashed up way in this 2*32 bit field.

fwiw,
Hein.

[A. Clay Stephenson]

Sometimes its best to ask the system itself.
A few days ago someone asked about the getdate() function and why it wouldn't work compiled at 32-bit code beyond 2038. While a struct tm should handle dates well beyond 2038 the reverse function would overflow. Curious, I then tried using getdate in a loop in 64-bit mode until it failed. The failure point was the year 2100. This was an arbitrary limit as opposed to the data siz limit imposed by 32-bit time_t values.

Here's the code if you wish to repeat the experiment:

First create a text file like this:
%m %d %Y

Next export the name of your date mask file:
export DATEMSK=/var/tmp/mydatemask

-----------------------------------


#include
#include
#include


int main()
{
int yr = 2037;
char s[80];
struct tm *t = NULL;


(void) sprintf(s,"01 01 %d",yr);
(void) printf("\nSize = %d\n",(int) sizeof(time_t));
t = getdate(s);
while (t != NULL && yr <= 10000)
{
(void) printf("Mo: %2d Day: %2d Year: %4d\n",
t->tm_mon + 1,t->tm_mday,t->tm_year + 1900);
++yr;
(void) sprintf(s,"01 01 %d",yr);
t = getdate(s);
}
if (t == NULL) (void) printf("Failed error = %d\n",getdate_err);
return(0);
}
-----------------------------------------

Compile like this:

cc datetest.c +DD64 -o datetest

You should then execute datetest and it should fail after 2099.