Date() beyond 2038-01-19, 03:14:07

[Little John]

//edit 2023-07-07
Code removed because it is obsolete now.
Please see my new DateEx module. Among other things, it provides replacements for all functions of PureBasic's Date library.

[CherokeeStalker]

The built-in procedures Date() as well as Year(), Month() etc. only use 32 bit, so that they only can work with values in the time range from 1970-01-01, 00:00:00 to 2038-01-19, 03:14:07 (his is not exactly documented in the help, BTW).

Anyone have a solution for dates PRIOR to 01-01-1970 - as in the 3rd or 4th century (300 AD) ?

[Little John]

Currently the constant #DATE_OFFSET is set to #DAYS_UNTIL_1970_01_01, in order to make my functions compatible with PureBasic's built-in date functions. You can set this constant to any value >= 0. If you simply set it to 0, you can calculate with all dates after Christ ... assuming that always the Gregorian calender had been used. This assumption is false, of course. But unless you do precise scientific historical calculations, this shouldn't be a big problem.
Setting #DATE_OFFSET to a value < 0 (before Christ) will probably not work correctly (I haven't tested it).

Regards, Little John

[CherokeeStalker]

The code contains the "date offset" #DAYS_UNTIL_1970_01_01 = 719163, in order to make it compatible with PureBasic's built-in date functions. You can change this offset to any value >= 0 (and then you should also rename the constant, since "DAYS_UNTIL_1970_01_01" would not be correct then anymore.) If you simply set it to 0, you can calculate with all dates after Christ ... assuming that always the Gregorian calender had been used. This assumption is false, of course. But unless you do precise scientific historical calculations, this shouldn't be a big problem.
Setting the "date offset" to a value < 0 (before Christ) will probably not work correctly (I haven't tested it).

Regards, Little John

Thanks. For anyone who doesn't know, use of the Gregorian calendar began
on 24-FEB-1582 !

[Kaeru Gaman]

For anyone who doesn't know, use of the Gregorian calendar began on 24-FEB-1582 !

this information is incomplete: you did not state the country.
the use of the gregorian calendar started in very different years all around the world!

[CherokeeStalker]

For anyone who doesn't know, use of the Gregorian calendar began on 24-FEB-1582 !

this information is incomplete: you did not state the country.
the use of the gregorian calendar started in very different years all around the world!

Very true - I made that post without stating the fact that that was when the (THEN) Pope made his decree. Thanks for reminding me of that.

[Rescator]

Or just use something based on Julian Day Number
http://emsai.net/projects/unidate/ (about)
http://emsai.net/projects/unidate/time/ (online example)
http://emsai.net/projects/unidate/source/ (source of example)

[Little John]

Or just use something based on Julian Day Number

Yep. The Julian date, for instance.

http://emsai.net/projects/unidate/ (about)

On that page, it reads:

µDate (pronounced Uni-Date) is a date standard,
independent of any terrestrial calendar or date systems.
It is my official proposal for UD (Universal Date).

I don't think that the proposal of a single person is the same thing as a standard ...

If someone does calculations only for her/himself, it probably wouldn't matter very much. Otherwise, I'd recommend using something that is better established, e.g. the Julian date.

Regards, Little John

[Kaeru Gaman]

those are old problems.

for example, to use a woldwide time of day, you normally use GMT.
(GMT in 24h notation is also known as ZULU)
also the Date-border is on the opposite side of the Greenwich meridian.

a fiew years ago swatch invented a 1/1000 daytime (1day devided in 1000 steps)
not based on GMT, but on CET, because switzerland is not located on GMT meridian.

I think it's a good idea to have a 1000steps/day clock,
but to be worldwide compatible it should be based on GMT.

something oldproved and wellknown like the Julian Date,
together with a 1/1000 daytime based on GMT,
this could build a Universal Date.

[Little John]

GMT is not used anymore. Its successor is UTC.

The fractional part [of the Julian date] gives the time of day since noon UT as a decimal fraction of one day or fractional day, with 0.5 representing midnight UT.

What's wrong with this? What would be the advantage of mixing it with "Swatch time"?

Regards, Little John

[Kaeru Gaman]

I just mentioned this as an example.
of course, the time of the day is a fraction of the date.
for use on a clock, a notation in 1/1000 date would be useful,
because people can recognise a 345.5 better than a 0.3455

perhaps it would take some time to get used to Terrestrial Time.
my idea just was to keep up with something we are used to,
thus I thought about a sync to GMT.

[Ollivier]

Hello !

This subject remember me I posted (after a recall of Dobro about definition of a date) a code giving the day since the 01/01/1900 (It was Monday!) I don't think there's limits excepted the need of the user.

[Rescator]

http://emsai.net/projects/unidate/ (about)

On that page, it reads:

µDate (pronounced Uni-Date) is a date standard,
independent of any terrestrial calendar or date systems.
It is my official proposal for UD (Universal Date).

I don't think that the proposal of a single person is the same thing as a standard ...

You do realize that most things are begun by a single individual? Then more follow and you end up with groups.

In any case, it is a standard as it's been published (on my site) and have been so for a few years now.

I also sent a proposal to USNO Time Department (the folks that run many of the Atomic time servers most of the world synchronize with), some universities and professors in the time fields.

Sadly, no answers. (no undelivered mail either)

Hopefully a standard similar to mine will be made one day as it's actually possible to memorize it unlike JDN (Julian Day Numbers) and it's MJDN and JD variants. (good luck remembering or communicating those)

and no, my system was not based on Star Trek despite some likeness. I simply choose 360 as a base as it's close to a year, it is somewhat easily computed using simple computer math etc. as explain on my site.

But to get back on topic. When doing calendar conversions, make sure to use JDN (Julian Day Numbers) as that is also what the scientific community is using to convert/calculate dates between old and new calendars.

[idle]

This thread is an interesting read.

Though I personally don't see the point in worrying about the date beyond 2038, not unless medical science has figured out how to extend my use by date, I'll probably be a babbling dribbling drunkard by then.

I.D.L.E (international date line east)

[Little John]

In any case, it is a standard as it's been published (on my site) and have been so for a few years now.

"Interesting" interpretation of the word standard.

Though I personally don't see the point in worrying about the date beyond 2038

Generally speaking, I think we can learn from the "Year 2K Problem", that it's a good idea to make our programs safe for the future in good time. The routines provided here have been requested on the German forum ( by a rather young fellow ). After writing them, I considered it not a bad idea to share them here, too.

Regards, Little John