Update FormatDate() and ParseDate() to the new date range

[DayDreamer]

Updated: Date library for full 64bit support (new range is year 1601 to 30827)

...

I hadn't the time to test PB 6.10 yet, but what I don't understand is the purpose of the new date range.... I would have expected that a greater supported range of around 29,000 years will go from history (let's say 20,000 BC) till future (e.g. year 9,000) to be usable for such purposes. Or do I see the goal of this new range not...

The range is a Windows API limitation. It comes from limits in the SYSTEMTIME and FILETIME structures (see here: https://learn.microsoft.com/en-us/windo ... systemtime)
We apply the same limit to the other OS to have a portable library with common limits.

It should be enough for all practical purposes. Dates like 20000BC make no sense to represent this way since the calendar we use did not exist then and it makes no sense to represent date and time that far back with a precision of seconds.

Having a cross platform standard date range defined by an operating system limitation (i.e. Windows) is compromised, shortsighted rationale IMHO. If you consider the subject of genealogy and family history, the recording of historical dates easily go earlier than 1601. Certainly linked historical records precede 1601 as well. It would be very valuable and practical if a generic date/calendar capability could be established that is agnostic of operating system. I understand there is a solution to this already with the Julian Day number system used as the underpinning for calendrical computations (not to be confused to Julian Date which is something different).

[jacdelad]

Keep in mind that there are also other libraries which should fit your genealogy problem.
I guess the internal function is made for file dates primarily, which it fits.

[Fred]

It's not short sighted, it's on purpose. The idea behind this is to have the PureBasic programs behave the same accross all supported OS, so we need to take in account for the OS limitations. As you said, if you need to have larger range for specific programs (genealogy etc) you can still have a third party module like this one: https://www.purebasic.fr/english/viewto ... t=calendar

[DayDreamer]

It's not short sighted, it's on purpose. The idea behind this is to have the PureBasic programs behave the same accross all supported OS, so we need to take in account for the OS limitations. As you said, if you need to have larger range for specific programs (genealogy etc) you can still have a third party module like this one: https://www.purebasic.fr/english/viewto ... t=calendar

I'm just expressing an opinion, feedback to consider. I certainly understand the deliberate rationale of striving to have the same "thing" across all supported OS ... indeed, the design intent of OS abstraction is what I love about PureBasic. Yes, it is necessary to work out what is practical to take into account OS limitations. I understand that perspective. But ...

Isn't it worth considering going further, where practical and feasible to do so, to consider introducing capability not constrained by OS limitations where there is a proven approach to do so? Third party libraries exist because they extend what is lacking in the core. In the case of calendars, having a core capability constrained to start at 1601 just looks quite odd. So perhaps my original critique is better directed at the Windows designers!

Thank you for pointing out the third party module. That is useful. For anyone interested in disappearing down the rabbit whole of calendars and their calculations, I can recommend the following:

Names: Reingold, Edward M., 1945– author. | Dershowitz, Nachum, author. Title: Calendrical calculations : the ultimate edition / Edward M. Reingold,
Illinois Institute of Technology, Chicago, Nachum Dershowitz, Tel Aviv University, Israel. Description: Fourth edition. | Cambridge : Cambridge University Press, 2017.
Identifiers: LCCN 2017024295| ISBN 9781107057623 (hardback)

[freak]

Introduced a new "%yyyyy" format token to handle 5 digit years. If used on a 4 digit year it will force a leading 0 in FormatDate() to ensure proper parsing in ParseDate().

The "%yyyy" format token is restricted to 4 digits output even if the year has 5 digits.

After thinking about this topic a bit more I have decided to revert this change and instead restrict the allowed year range for the library to year 9999 max to solve this issue. Year values up to 30827 really have no practical use and so complicating things for everybody just to make a theoretical case possible is not a good idea.

The purpose of this library is to be easy to use and consistent for the most common use cases. The previous range of 1970-2038 became too limited for this mostly due to the 2038 problem and not even primarily due to the 1970 limit. Having a now extended range of 1601-9999 is a great improvement over this and should fit almost every PB program just fine.

The arguments of trying to justify extreme ranges seem a bit made up to me. I have not seen many genealogy or archeology apps in PB yet and I do not think it is likely that PB will become popular in the nuclear waste management sector requiring year values in the +30000 range either. IF somebody were to write such a specialty app then THEY should bear the burden of the added complexity, not the average PB user who just wants a simple working date picker in their program.

Isn't it worth considering going further, where practical and feasible to do so, to consider introducing capability not constrained by OS limitations where there is a proven approach to do so?

It was considered and we decided it not to be feasible in this case. The date library has many points of interaction with OS components (CalendarGadget, DateGadget, File dates etc) which have to work reliably and consistently as well across all platforms. It is NOT just about parsing and printing dates. If these things don't work properly together then people would (rightfully) see that as a bug.

I have spend a lot more time on this Date library redesign that I would ever have imaged would be needed. There is a lot more complexity involved than you would think. Trust me: The limits we have now ARE the limits of what is practical and feasible.

Btw: The limits are just an implementation detail. It is always possible to extend them in the future in a backward compatible way if that becomes needed. Nothing is set in stone here.

[Sicro]

Or what other token should we use instead

That's why I have created this feature request that %yyyy should be changed so that it doesn't read the first 4 digits, but the last 4 digits. And there should be a new token %yyyyy (5 times "y") that can handle years with 5 digits.

How %yyyy currently works does not contradict how it is documented, because it was not written that it is the last 4 digits of the year. But yes, normally you would expect this, so it can be seen as a bug, even if it doesn't contradict the documentation. All good

Introduced a new "%yyyyy" format token to handle 5 digit years. If used on a 4 digit year it will force a leading 0 in FormatDate() to ensure proper parsing in ParseDate().

The "%yyyy" format token is restricted to 4 digits output even if the year has 5 digits.

That's ok for me.

Keep in mind that there are also other libraries which should fit your genealogy problem.
I guess the internal function is made for file dates primarily, which it fits.

That's how I see it too. Yes, specialized includes/modules/libraries should be used for much larger date ranges.

@Andre @DayDreamer
Of course, it would be nice if the native date library itself supported this, but it doesn't need to. But then it should be a separate calendar library, because the date ranges are then no longer compatible with the OS components (such as DateGadget()).

[Sicro]

After thinking about this topic a bit more I have decided to revert this change and instead restrict the allowed year range for the library to year 9999 max to solve this issue. Year values up to 30827 really have no practical use and so complicating things for everybody just to make a theoretical case possible is not a good idea.

Yes, it's better.

[Little John]

How %yyyy currently works does not contradict how it is documented

... and I never wrote that. I wrote this.
Well, since freak has now changed the valid date range, the problem has disappeared into thin air anyway.

[Sicro]

How %yyyy currently works does not contradict how it is documented

... and I never wrote that. I wrote this.

Ok, then you saw the lack of support for the new date range in the commands mentioned as a bug. Yes, it can be seen that way. I also wondered at first whether I should post it as a bug or a feature request. All good.

[Little John]

Code: Select all

; The last second of the year 1969 does not exist for FormatDate.

That is on purpose. The value -1 has always meant "invalid date" in the PB date library so we have to keep that for backward compatibility. Changing that would break a lot of code so having this one specific second be non-representable is the lesser of two evils here.

How about introducing a new function named say LastError() into PureBasic?
When that function does not indicate an error, then -1 is a valid date value.
In the documentation of LastError(), it can be written that the function currently only supports the Date library. If needed, support for other libraries can be added step by step with new PB releases. Just an idea.

[jacdelad]

How would this proposed function work when working with threads?

[mk-soft]

With compiler option thread safe

[jacdelad]

Ah ok. Makes sense.