Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[niubbo] convert a string representing a valid date to some "binary" date
100 views
Skip to first unread message
Soviet_Mario
Jul 17, 2019, 9:49:35 AM7/17/19
to
This one will surely sound very trivial to the skilled
programmers ...
I'm searching various standard binary date/time formats, but
I'm not finding functions that "build" a binary object from
a (valid, localized or not) string representation of a date
and/or time.
(the equivalent to strtod or atof for numbers)
In the string class, when dealing comparisons, I am trying
to implement also date comparisons (which requires a
conversion from textual, human readable, to binary format
supporting comparisons in itself) ....
and, well, I'm not managing to find a "reverse" conversion
(while there is plenty of functions outputting any binary
data format to textual format).
Also with scanf, I can't find any viable patch.
One thing : I'd need an input function smart enough to
support various date and/or time human-readable
representations, possibly ALL of them, a rather variable
scenario (short vs long, localized, UTC, just date, just
time, both, separators ? named day / month ?)
It is the kind of piece of code one would never want to
write by hand.
the string object will just have a bool flag like
"IsDateTime" set by the user, but the synthax of the
representation should be as much general as possible, so I
need a parsing function .... standard if there are some ...
any suggestion ?
TY
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
programmers ...
I'm searching various standard binary date/time formats, but
I'm not finding functions that "build" a binary object from
a (valid, localized or not) string representation of a date
and/or time.
(the equivalent to strtod or atof for numbers)
In the string class, when dealing comparisons, I am trying
to implement also date comparisons (which requires a
conversion from textual, human readable, to binary format
supporting comparisons in itself) ....
and, well, I'm not managing to find a "reverse" conversion
(while there is plenty of functions outputting any binary
data format to textual format).
Also with scanf, I can't find any viable patch.
One thing : I'd need an input function smart enough to
support various date and/or time human-readable
representations, possibly ALL of them, a rather variable
scenario (short vs long, localized, UTC, just date, just
time, both, separators ? named day / month ?)
It is the kind of piece of code one would never want to
write by hand.
the string object will just have a bool flag like
"IsDateTime" set by the user, but the synthax of the
representation should be as much general as possible, so I
need a parsing function .... standard if there are some ...
any suggestion ?
TY
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)
Soviet_Mario
Jul 17, 2019, 10:30:12 AM7/17/19
to
On 17/07/19 16:14, Stefan Ram wrote:
> Supersedes: <strftime-20...@ram.dialup.fu-berlin.de>
> and put_time/get_time from <iomanip>.
>
> Also check out 27.4.5 The time category [category.time] in n4800.
>
>
thanks, I'll inquire about them !
ah, meanwhile I did found sth here
https://pubs.opengroup.org/onlinepubs/009695399/functions/strptime.html
which is still not satisfactory, as this function require
the FORMAT of the textual data be known in advance, a demand
that cannot be fulfilled ...
I'm gonna read your suggestions. Ciao
> Supersedes: <strftime-20...@ram.dialup.fu-berlin.de>
>
> Soviet_Mario <Sovie...@CCCP.MIR> writes:
>> (the equivalent to strtod or atof for numbers)
>
> See: strftime, asctime from <ctime>, wcsftime from <cwchar>
> Soviet_Mario <Sovie...@CCCP.MIR> writes:
>> (the equivalent to strtod or atof for numbers)
>
> and put_time/get_time from <iomanip>.
>
> Also check out 27.4.5 The time category [category.time] in n4800.
>
>
thanks, I'll inquire about them !
ah, meanwhile I did found sth here
https://pubs.opengroup.org/onlinepubs/009695399/functions/strptime.html
which is still not satisfactory, as this function require
the FORMAT of the textual data be known in advance, a demand
that cannot be fulfilled ...
I'm gonna read your suggestions. Ciao
Öö Tiib
Jul 17, 2019, 3:52:57 PM7/17/19
to
On Wednesday, 17 July 2019 16:49:35 UTC+3, Soviet_Mario wrote:
> One thing : I'd need an input function smart enough to
> support various date and/or time human-readable
> representations, possibly ALL of them, a rather variable
> scenario (short vs long, localized, UTC, just date, just
> time, both, separators ? named day / month ?)
> It is the kind of piece of code one would never want to
> write by hand.
There are 6500 human languages and date is possible to write
> One thing : I'd need an input function smart enough to
> support various date and/or time human-readable
> representations, possibly ALL of them, a rather variable
> scenario (short vs long, localized, UTC, just date, just
> time, both, separators ? named day / month ?)
> It is the kind of piece of code one would never want to
> write by hand.
down in large number of ways in each of those so you should
perhaps drop C++ and take AI training courses.
In C++ we set either strongly fixed textual format or use GUI
"date picker" that provides binary format right away.
Keith Thompson
Jul 17, 2019, 4:28:16 PM7/17/19
to
For example, Perl has a "Date::Parse" module that does this.
I'd be surprised if there weren't something similar in C++.
Supporting *all* date forms is admittedly not possible. Some inputs
like "7/4/2019" are ambiguous.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
Scott Lurndal
Jul 17, 2019, 4:35:00 PM7/17/19
to
>On Wednesday, 17 July 2019 16:49:35 UTC+3, Soviet_Mario wrote:
>> One thing : I'd need an input function smart enough to
>> support various date and/or time human-readable
>> representations, possibly ALL of them, a rather variable
>> scenario (short vs long, localized, UTC, just date, just
>> time, both, separators ? named day / month ?)
>> It is the kind of piece of code one would never want to
>> write by hand.
Yes, if only it were part of a standard library. Oh, it is:
>> support various date and/or time human-readable
>> representations, possibly ALL of them, a rather variable
>> scenario (short vs long, localized, UTC, just date, just
>> time, both, separators ? named day / month ?)
>> It is the kind of piece of code one would never want to
>> write by hand.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/strptime.html
Soviet_Mario
Jul 17, 2019, 5:52:42 PM7/17/19
to
On 17/07/19 22:28, Keith Thompson wrote:
> Öö Tiib <oot...@hot.ee> writes:
>> On Wednesday, 17 July 2019 16:49:35 UTC+3, Soviet_Mario wrote:
>>> One thing : I'd need an input function smart enough to
>>> support various date and/or time human-readable
>>> representations, possibly ALL of them, a rather variable
>>> scenario (short vs long, localized, UTC, just date, just
>>> time, both, separators ? named day / month ?)
>>> It is the kind of piece of code one would never want to
>>> write by hand.
>>
>> There are 6500 human languages and date is possible to write
>> down in large number of ways in each of those so you should
>> perhaps drop C++ and take AI training courses.
>> In C++ we set either strongly fixed textual format or use GUI
>> "date picker" that provides binary format right away.
>
> Or we could use a parser that accepts a reasonable variety of formats.
+1
> Öö Tiib <oot...@hot.ee> writes:
>> On Wednesday, 17 July 2019 16:49:35 UTC+3, Soviet_Mario wrote:
>>> One thing : I'd need an input function smart enough to
>>> support various date and/or time human-readable
>>> representations, possibly ALL of them, a rather variable
>>> scenario (short vs long, localized, UTC, just date, just
>>> time, both, separators ? named day / month ?)
>>> It is the kind of piece of code one would never want to
>>> write by hand.
>>
>> There are 6500 human languages and date is possible to write
>> down in large number of ways in each of those so you should
>> perhaps drop C++ and take AI training courses.
>> In C++ we set either strongly fixed textual format or use GUI
>> "date picker" that provides binary format right away.
>
> Or we could use a parser that accepts a reasonable variety of formats.
many years ago I started to evaluate BOOST ... but was
really huge and didn't get to know it it has "fine grain"
enabling one to pick up just a couple of things needed.
BOOST had some parsin functions ... but it scared me then
(and it scares me now even more)
>
> For example, Perl has a "Date::Parse" module that does this.
> I'd be surprised if there weren't something similar in C++.
It has some string and built in DATE/TIME functions.
I've read a program can be made "a demon" (a TSR) so as a
last resort I could willy nilly write a small piece of
string-to-struct program to keep resident.
But I'm far from happy to try an inter-process data exchange.
>
> Supporting *all* date forms is admittedly not possible. Some inputs
> like "7/4/2019" are ambiguous.
>
which form. (gambas supports them and also perl-like RegEx)
To discover the format used in a date would be much easier
by RegEx patterns.
For Oo Tiib (sorry for the umlauth) : I have little control
over input formats, I'm collecting some user-filled online
forms and have to mangle them. Recent data are pre-filtered
using google modules/sheets and RegEx, but older data were
rather irregular.
Soviet_Mario
Jul 17, 2019, 5:55:57 PM7/17/19
to
<<
...
ah, meanwhile I did found sth here
https://pubs.opengroup.org/onlinepubs/009695399/functions/strptime.html
which is still not satisfactory, as this function require
the FORMAT of the textual data be known in advance, a demand
that cannot be fulfilled ...
I'm gonna read your suggestions. Ciao
>>
as I said, I don't know the format in advance and above all
https://pubs.opengroup.org/onlinepubs/009695399/functions/strptime.html
which is still not satisfactory, as this function require
the FORMAT of the textual data be known in advance, a demand
that cannot be fulfilled ...
I'm gonna read your suggestions. Ciao
>>
it's not taken for granted at all that every data will have
the same homogeneous format.
I need a parsing function aware of the human-written date-time.
But I'll also explore RegEx patterns to define narrower
contexts ...
Christian Gollwitzer
Jul 18, 2019, 1:06:18 AM7/18/19
to
Am 17.07.19 um 23:55 schrieb Soviet_Mario:
which tries to guess the format from the data, it's described here:
https://www.tcl.tk/man/tcl8.6/TclCmd/clock.htm#M80
But you'll get an "opinion" at best, because the problem is provably
impossible. Even humans cannot solve it perfectly. For example, if you
see this 05/07/19 it could be 5th of July 2019 or 7th of May 2019. The
first interpretation is more likely if it was written by a British
writer, the second one if it was written by an American. For 13/05/2019
it is not ambiguous, because there is no 13th month.
There is a list of traditional forms available here:
https://en.wikipedia.org/wiki/Date_format_by_country
You could pick the most likely formats from this list according to the
origin of your data, try to parse the string with each of them, check if
the month is between 1 and 12 and if there remains more than one
interpretation, throw an error.
If it is for a one off thing, e.g. you have a long list and want to
parse that once, I'd just use a Tcl script to convert the dates.
Christian
>
> as I said, I don't know the format in advance and above all it's not
> taken for granted at all that every data will have the same homogeneous
> format.
>
> I need a parsing function aware of the human-written date-time.
> But I'll also explore RegEx patterns to define narrower contexts ...
There are attempts to do that. For example, there is a functino Tcl
> as I said, I don't know the format in advance and above all it's not
> taken for granted at all that every data will have the same homogeneous
> format.
>
> I need a parsing function aware of the human-written date-time.
> But I'll also explore RegEx patterns to define narrower contexts ...
which tries to guess the format from the data, it's described here:
https://www.tcl.tk/man/tcl8.6/TclCmd/clock.htm#M80
But you'll get an "opinion" at best, because the problem is provably
impossible. Even humans cannot solve it perfectly. For example, if you
see this 05/07/19 it could be 5th of July 2019 or 7th of May 2019. The
first interpretation is more likely if it was written by a British
writer, the second one if it was written by an American. For 13/05/2019
it is not ambiguous, because there is no 13th month.
There is a list of traditional forms available here:
https://en.wikipedia.org/wiki/Date_format_by_country
You could pick the most likely formats from this list according to the
origin of your data, try to parse the string with each of them, check if
the month is between 1 and 12 and if there remains more than one
interpretation, throw an error.
If it is for a one off thing, e.g. you have a long list and want to
parse that once, I'd just use a Tcl script to convert the dates.
Christian
Paavo Helde
Jul 18, 2019, 2:33:59 AM7/18/19
to
for a long time! Sweet times! Too bad they are gone already for many years!
The idea to create a separate service/daemon for calling an external
program, just because boost::date_time looks too complicated, is just
hilarious! What happened to popen()?
Hint: the date/time handling looks complicated because it is. A good
start is to realize a single date lasts around 48 hours. So based on
datetime stamp it is not possible to say at which date the event
happened, even when leaving relativistic effects and Julius calendar out
of the play.
I have my own code based on Boost, for parsing dates in multiple
formats, but it only accepts non-ambiguous formats like "2018-03-01".
Anything with slashes is rejected as ambiguous, the caller must figure
them out beforehand.
> But I'm far from happy to try an inter-process data exchange.
only use the ISO datetime UTC format, e.g. "2005-12-31T14:30:25.00173Z".
Soviet_Mario
Jul 18, 2019, 8:44:40 AM7/18/19
to
I had said : I'm very rusty and old-fashioned-minded :)
>
> The idea to create a separate service/daemon for calling an
> external program, just because boost::date_time looks too
> complicated, is just hilarious!
problems, as I actually had never created a daemon, not to
say tried to communicate with. The gambas code in itself
would be trivial, but I suspect a lot of problems at
system-level
> What happened to popen()?
sorry ? I don't understand what you mean ...
>
> Hint: the date/time handling looks complicated because it
> is.
english formats and my "locale" (ita). No more than this.
And to refer to UTC as a frame reference.
> A good start is to realize a single date lasts around 48
> hours. So based on datetime stamp it is not possible to say
> at which date the event happened, even when leaving
> relativistic effects and Julius calendar out of the play.
>
> I have my own code based on Boost, for parsing dates in
> multiple formats, but it only accepts non-ambiguous formats
> like "2018-03-01". Anything with slashes is rejected as
> ambiguous, the caller must figure them out beforehand.
>
>> But I'm far from happy to try an inter-process data exchange.
>
> A side note: for portable inter-process date-time exchange
> one should only use the ISO datetime UTC format, e.g.
> "2005-12-31T14:30:25.00173Z".
to UTC, yes
Soviet_Mario
Jul 18, 2019, 8:50:38 AM7/18/19
to
On 18/07/19 07:06, Christian Gollwitzer wrote:
> Am 17.07.19 um 23:55 schrieb Soviet_Mario:
>>
>> as I said, I don't know the format in advance and above
>> all it's not taken for granted at all that every data will
>> have the same homogeneous format.
>>
>> I need a parsing function aware of the human-written
>> date-time.
>> But I'll also explore RegEx patterns to define narrower
>> contexts ...
>
>
> There are attempts to do that. For example, there is a
> functino Tcl which tries to guess the format from the data,
> it's described here:
> https://www.tcl.tk/man/tcl8.6/TclCmd/clock.htm#M80
>
> But you'll get an "opinion" at best, because the problem is
> provably impossible. Even humans cannot solve it perfectly.
> For example, if you see this 05/07/19 it could be 5th of
> July 2019 or 7th of May 2019. The first interpretation is
> more likely if it was written by a British writer, the
> second one if it was written by an American. For 13/05/2019
> it is not ambiguous, because there is no 13th month.
yes .... "some" extra data, not deduced from context, might
> Am 17.07.19 um 23:55 schrieb Soviet_Mario:
>>
>> as I said, I don't know the format in advance and above
>> all it's not taken for granted at all that every data will
>> have the same homogeneous format.
>>
>> I need a parsing function aware of the human-written
>> date-time.
>> But I'll also explore RegEx patterns to define narrower
>> contexts ...
>
>
> There are attempts to do that. For example, there is a
> functino Tcl which tries to guess the format from the data,
> it's described here:
> https://www.tcl.tk/man/tcl8.6/TclCmd/clock.htm#M80
>
> But you'll get an "opinion" at best, because the problem is
> provably impossible. Even humans cannot solve it perfectly.
> For example, if you see this 05/07/19 it could be 5th of
> July 2019 or 7th of May 2019. The first interpretation is
> more likely if it was written by a British writer, the
> second one if it was written by an American. For 13/05/2019
> it is not ambiguous, because there is no 13th month.
be profided to the parser to solve amgiguous cases.
>
> There is a list of traditional forms available here:
> https://en.wikipedia.org/wiki/Date_format_by_country
>
> You could pick the most likely formats from this list
> according to the origin of your data, try to parse the
> string with each of them, check if the month is between 1
> and 12 and if there remains more than one interpretation,
> throw an error.
>
> If it is for a one off thing, e.g. you have a long list and
> want to parse that once, I'd just use a Tcl script to
> convert the dates.
Thanks for reply
>
> Christian
James Kuyper
Jul 18, 2019, 9:24:58 AM7/18/19
to
On 7/18/19 8:44 AM, Soviet_Mario wrote:
...
ISO 8601
<https://en.wikipedia.org/wiki/ISO_8601> doesn't refer to a single
format, but a family of closely related formats. For instance, you can
leave out trailing parts, such as the seconds, minutes, hour, day, or
month. You can also use 2019-W15-5 to indicate the 5th day of the 15th
week of 2019, or 2019-123 to refer to the 123rd day of 2019.
Just covering all of the variants of ISO 8601 will be a complicated but
well defined task, and careful attention has been taken to make sure
that the interpretation is never ambiguous. Once you have completed
that, you can decide whether you want to go on to cover other date formats.
I predict you'll get tired of dealing with all the complications of date
formats long before you finish.
...
> yes I know. To restrict the scope, I just want to support
> english formats and my "locale" (ita). No more than this.
> And to refer to UTC as a frame reference.
Before you attempt anything that ambitious, I recommend you start small:
> english formats and my "locale" (ita). No more than this.
> And to refer to UTC as a frame reference.
ISO 8601
<https://en.wikipedia.org/wiki/ISO_8601> doesn't refer to a single
format, but a family of closely related formats. For instance, you can
leave out trailing parts, such as the seconds, minutes, hour, day, or
month. You can also use 2019-W15-5 to indicate the 5th day of the 15th
week of 2019, or 2019-123 to refer to the 123rd day of 2019.
Just covering all of the variants of ISO 8601 will be a complicated but
well defined task, and careful attention has been taken to make sure
that the interpretation is never ambiguous. Once you have completed
that, you can decide whether you want to go on to cover other date formats.
I predict you'll get tired of dealing with all the complications of date
formats long before you finish.
Keith Thompson
Jul 18, 2019, 4:41:17 PM7/18/19
to
Soviet_Mario <Sovie...@CCCP.MIR> writes:
> On 18/07/19 08:33, Paavo Helde wrote:
[...]
> On 18/07/19 08:33, Paavo Helde wrote:
>> The idea to create a separate service/daemon for calling an
>> external program, just because boost::date_time looks too
>> complicated, is just hilarious!
>
> well, maybe. I must admit I have no real idea of the
> problems, as I actually had never created a daemon, not to
> say tried to communicate with. The gambas code in itself
> would be trivial, but I suspect a lot of problems at
> system-level
>
>> What happened to popen()?
>
> sorry ? I don't understand what you mean ...
If you're on a UNIX-like system, run the "man popen" command.
>> external program, just because boost::date_time looks too
>> complicated, is just hilarious!
>
> well, maybe. I must admit I have no real idea of the
> problems, as I actually had never created a daemon, not to
> say tried to communicate with. The gambas code in itself
> would be trivial, but I suspect a lot of problems at
> system-level
>
>> What happened to popen()?
>
> sorry ? I don't understand what you mean ...
popen() is a function, defined by POSIX (but not by the C or C++
standard) that lets you invoke an external command and capture
its output. Using it is *much* simpler than creating a daemon and
setting up a communication channel. I believe it's also available
under Windows.
Öö Tiib
Jul 19, 2019, 12:12:20 AM7/19/19
to
On Thursday, 18 July 2019 00:52:42 UTC+3, Soviet_Mario wrote:
>
> For Oo Tiib (sorry for the umlauth) : I have little control
> over input formats, I'm collecting some user-filled online
> forms and have to mangle them. Recent data are pre-filtered
> using google modules/sheets and RegEx, but older data were
> rather irregular.
Online forms also have usually date pickers.
>
> For Oo Tiib (sorry for the umlauth) : I have little control
> over input formats, I'm collecting some user-filled online
> forms and have to mangle them. Recent data are pre-filtered
> using google modules/sheets and RegEx, but older data were
> rather irregular.
https://jqueryui.com/datepicker/
Who programs date entry as random free form text at 2019?
Soviet_Mario
Jul 19, 2019, 5:14:44 AM7/19/19
to
On 18/07/19 22:41, Keith Thompson wrote:
> Soviet_Mario <Sovie...@CCCP.MIR> writes:
>> On 18/07/19 08:33, Paavo Helde wrote:
> [...]
>>> The idea to create a separate service/daemon for calling an
>>> external program, just because boost::date_time looks too
>>> complicated, is just hilarious!
>>
>> well, maybe. I must admit I have no real idea of the
>> problems, as I actually had never created a daemon, not to
>> say tried to communicate with. The gambas code in itself
>> would be trivial, but I suspect a lot of problems at
>> system-level
>>
>>> What happened to popen()?
>>
>> sorry ? I don't understand what you mean ...
>
> If you're on a UNIX-like system, run the "man popen" command.
the thing I did not understand was : "why did you mention
> Soviet_Mario <Sovie...@CCCP.MIR> writes:
>> On 18/07/19 08:33, Paavo Helde wrote:
> [...]
>>> The idea to create a separate service/daemon for calling an
>>> external program, just because boost::date_time looks too
>>> complicated, is just hilarious!
>>
>> well, maybe. I must admit I have no real idea of the
>> problems, as I actually had never created a daemon, not to
>> say tried to communicate with. The gambas code in itself
>> would be trivial, but I suspect a lot of problems at
>> system-level
>>
>>> What happened to popen()?
>>
>> sorry ? I don't understand what you mean ...
>
> If you're on a UNIX-like system, run the "man popen" command.
such command" ?
>
> popen() is a function, defined by POSIX (but not by the C or C++
> standard) that lets you invoke an external command and capture
> its output. Using it is *much* simpler than creating a daemon and
> setting up a communication channel. I believe it's also available
> under Windows.
Yes it simple, but imply multiple invocations not just
"calls". But yes, "shelling" processes is a fallback
solution, surely
TY
Soviet_Mario
Jul 19, 2019, 5:16:44 AM7/19/19
to
time. I mean : data are just existing, I'm not collecting
them for the future.
Tnx
David Brown
Jul 19, 2019, 5:28:00 AM7/19/19
to
still be simpler than writing a daemon.
In the *nix world, creating processes is cheap. There is often little
problem in using a process simply to handle one call like this.
Öö Tiib
Jul 19, 2019, 6:47:30 AM7/19/19
to
On Friday, 19 July 2019 12:16:44 UTC+3, Soviet_Mario wrote:
> On 19/07/19 06:12, Öö Tiib wrote:
> > On Thursday, 18 July 2019 00:52:42 UTC+3, Soviet_Mario wrote:
> >>
> >> For Oo Tiib (sorry for the umlauth) : I have little control
> >> over input formats, I'm collecting some user-filled online
> >> forms and have to mangle them. Recent data are pre-filtered
> >> using google modules/sheets and RegEx, but older data were
> >> rather irregular.
> >
> > Online forms also have usually date pickers.
> > https://jqueryui.com/datepicker/
> > Who programs date entry as random free form text at 2019?
> >
> >
>
> I should deal with students old reports, dating back some
> time. I mean : data are just existing, I'm not collecting
> them for the future.
> Tnx
If I would have lot of such dirty data then i would just
> On 19/07/19 06:12, Öö Tiib wrote:
> > On Thursday, 18 July 2019 00:52:42 UTC+3, Soviet_Mario wrote:
> >>
> >> For Oo Tiib (sorry for the umlauth) : I have little control
> >> over input formats, I'm collecting some user-filled online
> >> forms and have to mangle them. Recent data are pre-filtered
> >> using google modules/sheets and RegEx, but older data were
> >> rather irregular.
> >
> > Online forms also have usually date pickers.
> > https://jqueryui.com/datepicker/
> > Who programs date entry as random free form text at 2019?
> >
> >
>
> I should deal with students old reports, dating back some
> time. I mean : data are just existing, I'm not collecting
> them for the future.
> Tnx
try some set of std::get_time locales and formats.
https://en.cppreference.com/w/cpp/io/manip/get_time
More important is there to report dates that feel wrong
or are ambiguous like 07/03/19. It takes human operator
to guess if it was meant 2007/March/19, 07/March/2019,
July/03/2019 or undecidable ambiguous.
Ben Bacarisse
Jul 19, 2019, 1:29:01 PM7/19/19
to
mobile, voice input it a boon. Most date pickers are a pain compared to
simply saying the date. "Progress" is inevitable!
--
Ben.
Keith Thompson
Jul 19, 2019, 2:34:19 PM7/19/19
to
Ben Bacarisse <ben.u...@bsb.me.uk> writes:
And if you have an existing date as text, it's good to be able to
copy-and-paste it.
copy-and-paste it.
Öö Tiib
Jul 19, 2019, 9:12:02 PM7/19/19
to
On Friday, 19 July 2019 20:29:01 UTC+3, Ben Bacarisse wrote:
:D That is why I suggested AI training courses up-thread. It is
pain to manually write a speech recognition as C++ but once
it is trained ... it is just couple of matrix multiplications.
pain to manually write a speech recognition as C++ but once
it is trained ... it is just couple of matrix multiplications.
Soviet_Mario
Jul 19, 2019, 10:15:07 PM7/19/19
to
it for 2 years), and I must admit I can't tell the
difference from an "open process" and a Daemon.
The fact is : I actually still dunno what's a daemon.
As for an open process, I could simply think of some process
with a "polling loop" on input, which processes commands for
Stdin (or a Pipe) until some special input is received, like
"die !". Or even a signal (gambas supports natively signalling).
It is a damn good and simple idea (If I have got it right).
Thank you !!!!
Soviet_Mario
Jul 20, 2019, 7:40:38 AM7/20/19
to
and known in advance.
Now I have the suspect that the target was too ambitious (as
many said since start)
David Brown
Jul 20, 2019, 7:40:38 AM7/20/19
to
performing services. Usually they are started automatically at system
bootup, and usually they communicate on network sockets. A webserver is
a daemon - it waits around until someone sends it an http query on a
TCP/IP port, it responds to the query, and goes back to waiting. You
have dozens of daemons running on a typical Linux system (and Windows
has services doing the same job under a different name), handling mail,
time-scheduled tasks, bluetooth, networking, time protocols, and all
sorts of other things. I am not sure if there is a clear and absolute
definition of what makes a program a daemon, but if there is then it is
outside the scope of c.l.c++.
> As for an open process, I could simply think of some process with a
> "polling loop" on input, which processes commands for Stdin (or a Pipe)
> until some special input is received, like "die !". Or even a signal
> (gambas supports natively signalling).
involve a bit more effort, and usually involve being "root" for at least
some of the time (giving more power, but also more responsibility).
Forget signals if you can - they are blunt instruments and fiddly to get
right. And in this case, your helper program can read from stdin and
write to stdout - it is up to the calling process to make the pipes.
>
> It is a damn good and simple idea (If I have got it right). Thank you !!!!
>
Christian Gollwitzer
Jul 20, 2019, 8:31:36 AM7/20/19
to
Am 18.07.19 um 14:50 schrieb Soviet_Mario:
line by line and converts the date into POSIX time:
===============
set fd [open date_input.txt r]
set lines [split [read $fd] \n]
close $fd
set fd [open date_parsed.txt w]
foreach d $lines {
set result {}
if {[catch {clock scan $d} unixtime]} {
# error occured
lappend result $d NaN $unixtime
} else {
set formatted [clock format $unixtime]
lappend result $d $unixtime $formatted
}
puts $fd [join $result \t]
}
close $fd
===============
On this input
======== date_input.txt ===========
next July
04/05/2019
12 Oct 2011
March 3
Tomorrow
next line gives error
02.04.2019
3 Aug 2018 08:03
===================================
The output is
============= date_parsed.txt =====
next July 1595196000 Mon Jul 20 00:00:00 CEST 2020
04/05/2019 1554415200 Fri Apr 05 00:00:00 CEST 2019
12 Oct 2011 1318370400 Wed Oct 12 00:00:00 CEST 2011
March 3 1551567600 Sun Mar 03 00:00:00 CET 2019
Tomorrow 1563660000 Sun Jul 21 00:00:00 CEST 2019
next line gives error NaN unable to convert date-time string "next line
gives error": syntax error (characters 4-8)
02.04.2019 NaN unable to convert date-time string "02.04.2019": syntax
error (characters 2-2)
3 Aug 2018 08:03 1533276180 Fri Aug 03 08:03:00 CEST 2018
===================================
As you can see, it is America-centric, unfortunately. It parses
04/05/2019 as April 5th. The British form 05/04/19 is incorrectly
parsed, and the German format 05.04.2019 is rejected. So maybe with
manual control it could help for a one-off list depending on the
cultural background.
Christian
>> If it is for a one off thing, e.g. you have a long list and want to
>> parse that once, I'd just use a Tcl script to convert the dates.
>
> unfortunately I dont know TCL
> Thanks for reply
>
Not sure if this will help. Here is a short script which reads a file
>> parse that once, I'd just use a Tcl script to convert the dates.
>
> unfortunately I dont know TCL
> Thanks for reply
>
line by line and converts the date into POSIX time:
===============
set fd [open date_input.txt r]
set lines [split [read $fd] \n]
close $fd
set fd [open date_parsed.txt w]
foreach d $lines {
set result {}
if {[catch {clock scan $d} unixtime]} {
# error occured
lappend result $d NaN $unixtime
} else {
set formatted [clock format $unixtime]
lappend result $d $unixtime $formatted
}
puts $fd [join $result \t]
}
close $fd
===============
On this input
======== date_input.txt ===========
next July
04/05/2019
12 Oct 2011
March 3
Tomorrow
next line gives error
02.04.2019
3 Aug 2018 08:03
===================================
The output is
============= date_parsed.txt =====
next July 1595196000 Mon Jul 20 00:00:00 CEST 2020
04/05/2019 1554415200 Fri Apr 05 00:00:00 CEST 2019
12 Oct 2011 1318370400 Wed Oct 12 00:00:00 CEST 2011
March 3 1551567600 Sun Mar 03 00:00:00 CET 2019
Tomorrow 1563660000 Sun Jul 21 00:00:00 CEST 2019
next line gives error NaN unable to convert date-time string "next line
gives error": syntax error (characters 4-8)
02.04.2019 NaN unable to convert date-time string "02.04.2019": syntax
error (characters 2-2)
3 Aug 2018 08:03 1533276180 Fri Aug 03 08:03:00 CEST 2018
===================================
As you can see, it is America-centric, unfortunately. It parses
04/05/2019 as April 5th. The British form 05/04/19 is incorrectly
parsed, and the German format 05.04.2019 is rejected. So maybe with
manual control it could help for a one-off list depending on the
cultural background.
Christian
Soviet_Mario
Jul 20, 2019, 9:44:57 AM7/20/19
to
Ciao
Soviet_Mario
Jul 20, 2019, 9:46:35 AM7/20/19
to
16 code lines to do that ... I'll read sth about TCL !
thanks
Vir Campestris
Jul 22, 2019, 4:56:49 PM7/22/19
to
holiday this year in the US, the 7th April this year in most of the
world, and quite possibly 19th April 2007 if you are in China.
(we always write 2019/04/07 when dealing with international messages.
Everyone reads that the same!)
Andy
Keith Thompson
Jul 22, 2019, 6:04:16 PM7/22/19
to
Vir Campestris <vir.cam...@invalid.invalid> writes:
[...]
The international standard format, ISO 8601, is 2019-04-07 (April 7, 2019).
I strongly suggest using that if at all possible.
[...]
> (we always write 2019/04/07 when dealing with international messages.
> Everyone reads that the same!)
I wouldn't be too sure that *everyone* would read 2019/04/07 the same way.
> Everyone reads that the same!)
The international standard format, ISO 8601, is 2019-04-07 (April 7, 2019).
I strongly suggest using that if at all possible.
Christian Gollwitzer
Jul 23, 2019, 2:29:52 AM7/23/19
to
Am 22.07.19 um 22:56 schrieb Vir Campestris:
writer. He could mark ambiguous dates and check them manually, but in
principle the problem has no solution.
Christian
> And I'll leave you to worry about whether 07/04/19 was the national
> holiday this year in the US, the 7th April this year in most of the
> world, and quite possibly 19th April 2007 if you are in China.
That was discussed before. It depends on the cultural background of the
> holiday this year in the US, the 7th April this year in most of the
> world, and quite possibly 19th April 2007 if you are in China.
writer. He could mark ambiguous dates and check them manually, but in
principle the problem has no solution.
Christian
Jorgen Grahn
Aug 1, 2019, 9:19:15 AM8/1/19
to
On Mon, 2019-07-22, Keith Thompson wrote:
> Vir Campestris <vir.cam...@invalid.invalid> writes:
> [...]
>> (we always write 2019/04/07 when dealing with international messages.
>> Everyone reads that the same!)
>
> I wouldn't be too sure that *everyone* would read 2019/04/07 the same way.
>
> The international standard format, ISO 8601, is 2019-04-07 (April 7, 2019).
> I strongly suggest using that if at all possible.
Yes, please. As a non-US person, I have to stop and think about
> Vir Campestris <vir.cam...@invalid.invalid> writes:
> [...]
>> (we always write 2019/04/07 when dealing with international messages.
>> Everyone reads that the same!)
>
> I wouldn't be too sure that *everyone* would read 2019/04/07 the same way.
>
> The international standard format, ISO 8601, is 2019-04-07 (April 7, 2019).
> I strongly suggest using that if at all possible.
2019/04/07, although I'll soon conclude it's unambiguous.
ISO dates OTOH are immediately familiar to me.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Scott Lurndal
Aug 1, 2019, 10:10:34 AM8/1/19
to
Jorgen Grahn <grahn...@snipabacken.se> writes:
>On Mon, 2019-07-22, Keith Thompson wrote:
>> Vir Campestris <vir.cam...@invalid.invalid> writes:
>> [...]
>>> (we always write 2019/04/07 when dealing with international messages.
>>> Everyone reads that the same!)
>>
>> I wouldn't be too sure that *everyone* would read 2019/04/07 the same way.
>>
>> The international standard format, ISO 8601, is 2019-04-07 (April 7, 2019).
>> I strongly suggest using that if at all possible.
>
>Yes, please. As a non-US person, I have to stop and think about
>2019/04/07, although I'll soon conclude it's unambiguous.
Moreover, it's trivially sortable.
>On Mon, 2019-07-22, Keith Thompson wrote:
>> Vir Campestris <vir.cam...@invalid.invalid> writes:
>> [...]
>>> (we always write 2019/04/07 when dealing with international messages.
>>> Everyone reads that the same!)
>>
>> I wouldn't be too sure that *everyone* would read 2019/04/07 the same way.
>>
>> The international standard format, ISO 8601, is 2019-04-07 (April 7, 2019).
>> I strongly suggest using that if at all possible.
>
>Yes, please. As a non-US person, I have to stop and think about
>2019/04/07, although I'll soon conclude it's unambiguous.
Jorgen Grahn
Aug 2, 2019, 2:20:10 AM8/2/19
to
both trivially sortable.
James Kuyper
Aug 2, 2019, 8:43:34 AM8/2/19
to
On 8/2/19 2:20 AM, Jorgen Grahn wrote:
> On Thu, 2019-08-01, Scott Lurndal wrote:
>> Jorgen Grahn <grahn...@snipabacken.se> writes:
>>> On Mon, 2019-07-22, Keith Thompson wrote:
...
> On Thu, 2019-08-01, Scott Lurndal wrote:
>> Jorgen Grahn <grahn...@snipabacken.se> writes:
>>> On Mon, 2019-07-22, Keith Thompson wrote:
>>>> The international standard format, ISO 8601, is 2019-04-07 (April 7, 2019).
>>>> I strongly suggest using that if at all possible.
>>>
>>> Yes, please. As a non-US person, I have to stop and think about
>>> 2019/04/07, although I'll soon conclude it's unambiguous.
>>
>> Moreover, it's trivially sortable.
>
> We were comparing 2019/04/07 and 2019-04-07 in this subthread, so they're
> both trivially sortable.
It its, however, mildly non-trivial to sort a list containing a mixture
>>>> I strongly suggest using that if at all possible.
>>>
>>> Yes, please. As a non-US person, I have to stop and think about
>>> 2019/04/07, although I'll soon conclude it's unambiguous.
>>
>> Moreover, it's trivially sortable.
>
> We were comparing 2019/04/07 and 2019-04-07 in this subthread, so they're
> both trivially sortable.
of those two formats - which is why it's better to adhere to an official
standard.
James Kuyper
Aug 2, 2019, 9:40:05 AM8/2/19
to
On 8/2/19 9:18 AM, Stefan Ram wrote:
> I do not interpret "2019/04/07" to be "trivially sortable",
> because I do not know whether it's "YYYY/MM/DD" or "YYYY/DD/MM".
True - according to
<https://en.wikipedia.org/wiki/Calendar_date#Gregorian,_year-day-month_(YDM)>
, the latter format is used in Kazakhstan, Latvia, Nepal, and
Turkmenistan - though strictly speaking, the Kazakhstani format uses '.'
rather than '/' as the separator.
However, in many contexts the possibility that the dates are in that
format is negligibly small (though not exactly 0.0%). It isn't even
shown on the usage map or the accompanying table on that same web page,
and yyyy/dd/mm occurs nowhere on
<https://en.wikipedia.org/wiki/Date_format_by_country>.
(Latvia, Nepal, and Turkmenistan are all missing from that list).
According to the table on the Calendar_date page, more than half the
world's population lives in places where YMD is one of the commonly used
formats; 1,678,000,000 live in places where it's the only format.
> because I do not know whether it's "YYYY/MM/DD" or "YYYY/DD/MM".
True - according to
<https://en.wikipedia.org/wiki/Calendar_date#Gregorian,_year-day-month_(YDM)>
, the latter format is used in Kazakhstan, Latvia, Nepal, and
Turkmenistan - though strictly speaking, the Kazakhstani format uses '.'
rather than '/' as the separator.
However, in many contexts the possibility that the dates are in that
format is negligibly small (though not exactly 0.0%). It isn't even
shown on the usage map or the accompanying table on that same web page,
and yyyy/dd/mm occurs nowhere on
<https://en.wikipedia.org/wiki/Date_format_by_country>.
(Latvia, Nepal, and Turkmenistan are all missing from that list).
According to the table on the Calendar_date page, more than half the
world's population lives in places where YMD is one of the commonly used
formats; 1,678,000,000 live in places where it's the only format.
0 new messages