Leaderboard

Why a Delphi 10.4.1 CE edition does not exist? The CE is still in 10.3 version...

Pepto-Bismol might help with that...

If you need to handle time zones all around the world, for users and senders in different time zones, I recommend TZDB from https://github.com/pavkam/tzdb. It is essentially a single PAS file which has all the TZ and DST data and functions you need. There are also other tools, including one to update the source code from the IANA database, which is updated a few times a year. Of course you also need to follow the advice above about how to parse the input! As I have said here before, I suggest tweaking the database extraction tool to exclude all the historical data, which it seems unlikely you will need.

https://github.com/Pigrecos/Keras4Delphi/tree/master/src/NumPy In my partial conversion, there is something about it

Simple - I never had a need for it in my production software. Oh sure, the technology was fun to work with, and all. I used it on my company's website for awhile to help new users navigate around the site, and in demo softwares to guide new users around screens and features, and in slideshows to explain to viewers what was being shown. But, in the end, it did not serve much practical use otherwise that couldn't be done in other simpler/more efficient ways. No. Microsoft itself used it in some of their released software. Look at the (negative) feedback they got from that. Not many people liked it. Of course, that was not the fault of the technology itself, but in the annoying ways in which Microsoft decided to use it.

Yes. It strips off the UTC offset portion, and converts the remaining string as-is to TDateTime form. Yes. It is intended to convert UTC offset strings into TDateTime form, which are then added to/subtracted from TDateTime values returned by Raw/StrInternetToDateTime(). You can thank popular Internet protocols for that, with their long history of using non-standardized date/time formats. Much of which went away with standardized ISO 8601 formats. In your case, I would probably suggest simply parsing the date/time string backwards, token by token. If a token is in "(<timezone>)" format, you would have to manually convert it to the corresponding UTC offset (which sadly changes frequently in many timezones). Indy has a TimeZoneToGmtOffsetStr() function that does this, but it is private to the IdGlobalProtocols unit, it is used internally by GmtOffsetStrToDateTime(). If a token is in "±HHMM" format, then it is trivial to convert it as-is to a UTC offset. Sounds like it may be useful to add a new function to Indy, which takes in a date/time string as input and just splits it up into its various components as output. Maybe as a helper for RawStrInternetToDateTime() to call internally. Indy has TimeZoneBias() and OffsetFromUTC() functions, which return the current UTC offset in TDateTime form. Indy also has functions it is not a bug. As it should be.. Operating systems are not very good about keeping accurate history of past time zones. And in any case, date/time strings in this format as supposed to be self-contained, not relying on PC clock data at all. A string like "Sun, 8 Jul 2020 06:55:38 -0800 (PST)" literally claims to represent July 8 2020 at 6:55:38 AM in a timezone that is -8 hours from UTC, Period. Regardless of the fact that on July 8 2020 the Pacific time zone was actually operating in PDT and not in PST. So any competent software producing this date/time string at that time would have produced "Sun, 8 Jul 2020 06:55:38 -0700 (PDT)" instead, which is the correct string for that date/time. By lying to the parser, you are not going to get the result you want. And it is not fair to ask Indy to go digging through the OS or the Internet trying to verify if the date/time string is accurate or not. The string is taken at face value. Right, because your PC would be operating in the PDT time zone needed for July 8 2020, not in the PST time zone needed for Nov 8 2020. You would have needed to adjust the timezone info in the date/time string accordingly, not just the date. Yes, RawStrInternetToDateTime() converts and strips off the date/time portion of the string, modifying the string to leave the UTC offset portion, which can then be passed to GmtOffsetStrToDateTime(). You would have to parse the date/time string manually, none of Indy's existing public functions are designed for the specific task you are trying to accomplish. The private functions that would accomplish it are, well, private. And for one simple reason - because nobody ever asked for them to be made public before.

I'll need some more mushrooms to fully decipher that.

It should be mentioned that one of the package units registers the new file format: initialization TPicture.RegisterFileFormat('SVG', 'Scalable Vector Graphics', TSVGGraphic); Use PowerToys to get SVG preview at run time when you disable Vcl styles. (Also in File Explorer)