This repository has been archived by the owner on Feb 27, 2024. It is now read-only.
Changes for compiling in Delphi XE8, 2010 and 6 #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A record and function were not defined in Windows.h for Windows 2010.
D6 does not have UInt64. Using Int64Rec instead. D6 does not have class constructor or generics. Falls back to only using local time zone.
alex-ilin
pushed a commit
to alex-ilin/superobject
that referenced
this pull request
Sep 6, 2019
Improved Delpi version handling
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I propose these changes. The first 2 commits, for XE8 and D2010, are obvious.
The third commit, for D6, may be controversial, since I "ifdef away" any generics/class constructor/delayed code, and just lock the timezone to be local (+02:00 here in Norway in the summer) when using that Delphi version (or rather any version below D2010).
(I could have chosen the UTC timezone for D6 (resulting in a single Z at the end of the time string). Or, it seems that I get no timezone info at all in the DelphiDateTimeToISO8601Date result string when requesting a non-existent timezone name. But I thought maybe the local timezone would be the best compromise.)
I hope this is acceptable as a graceful degradation when generics/class constructors are not available.
::tor