Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции FTSC_PUBLIC
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции FTSC_PUBLIC с датами от 13 Sep 13 18:57:24 до 15 Nov 24 00:30:01, всего сообщений: 7128
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 5885 из 7128 ====================================== FTSC_PUBLIC =
От   : mark lewis                       1:3634/12.73       14 Jan 22 18:21:50
Кому : Maurice Kinal                                       14 Jan 22 18:21:50
Тема : Unix point?
FGHI : area://FTSC_PUBLIC?msgid=1:3634/12.73+61e20593
На   : area://FTSC_PUBLIC?msgid=1:153/7001+61e1dcb8
= Кодировка сообщения определена как: CP437 ==================================
Ответ: area://FTSC_PUBLIC?msgid=1:153/7001+61e20c9f
==============================================================================

 On 2022 Jan 14 20:27:36, you wrote to me:

ml>> not all proposals are accepted or if accepted, stick around...

MK> Too bad they missed out on the opportunity to not accept a few of them
MK> that stick around when they have no right to exist in the first place.

that's your opinion... i won't even ask who it is you think assigns any so-called rights to any proposals' existence...

ml>> somewhere inside it, there is a conversion from string to numerics
ml>> and back to string again

MK> No doubt.

thank you...

MK> However it REQUIRES the first character in the string to be either a
MK> '+' (east) or a '-' (west).  Note the REQUIRE and that is part and
MK> parcel of the offset ... which is always a string ... which is always
MK> NaN.

you keep forgetting to add "in your chosen routine" to your statements... other routines that do the same or similar job do not have such a requirement...

MK> Dropping the '+' character ist vorboten.

mmmhummm... no '+' here... plus you just said that it could be one of two specific characters so...

  TZ=UTC date --rfc-3339=sec --date="14 Jan 2022  22:27:36 -0000"
  2022-01-14 22:27:36+00:00

then there's this which also works just fine IF you like the ISO8601 format... some do not care for it...

  TZ=UTC date --rfc-3339=sec --utc
  2022-01-14 22:27:36+00:00

but you already know these things and are just trying to get your jollies arguing about something... meh... i'm done because it isn't worth it, it is a very old argument (like 2 decades now you've been going on about this??), and simply said, it is not what the developer who wrote the accepted spec decided to use...


PS: yes, i did time my use of the above 2nd date call (with --utc) to match the example naturally :)

PPS: i also note your use of a two-digit year in your examples ;)

PPPS: the resulting '+' or '-' on the time zone is likely due to the use of a boolean array where only true or false are allowed...

eg:
  const
    FmtOffset: string = '%.02d%.02d';
    Sign: array[Boolean] of Char = ('+', '-');

  var
    LocalTimeOffset: Integer;

  begin
    LocalTimeOffset := GetLocalTimeOffset;
    Writeln (FormatDateTime('YYYY MMM DD hh:mm:ss', Now) + ' ' + Sign[LocalTimeOffset>0],
             Format(FmtOffset, [LocalTimeOffset div MinsPerHour, LocalTimeOffset mod MinsPerHour]));
  end.

  2022 Jan 14 17:27:36 -0500


)\/(ark

"The soul of a small kitten in the body of a mighty dragon. Look on my majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
... Remember: Landings should always equal takeoffs!
---
* Origin:  (1:3634/12.73)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.057528 секунды