473,326 Members | 2,099 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

Checking for a valid date

What's the easiest way to verify the user had entered a valid date ?
Nov 21 '05 #1
28 1985
"romy" <ro******@Powerup1.com> schrieb
What's the easiest way to verify the user had entered a valid date ?


Call Date.Parse in a Try/Catch block. If there's no excecption the date was
valid.
Armin

Nov 21 '05 #2


romy wrote:
What's the easiest way to verify the user had entered a valid date ?


The IsDate() function.

--
Larry Lard
Replies to group please

Nov 21 '05 #3
"romy" <ro******@Powerup1.com> schrieb:
What's the easiest way to verify the user had entered a valid date ?


'Microsoft.VisualBasic.Information.IsDate'.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Nov 21 '05 #4
I recommend against this method in most cases; exceptions are
resource-intensive and shouldn't really be used for raw user-data
validation. It probably wouldn't matter much on a Win Forms app, but I
would really back away from this on ASP.NET if you're expecting any
volume of traffic.

The IsDate would be a better way to go.

Jason

www.pettysconsulting.com
Armin Zingler wrote:
"romy" <ro******@Powerup1.com> schrieb
What's the easiest way to verify the user had entered a valid date ?


Call Date.Parse in a Try/Catch block. If there's no excecption the date
was valid.
Armin

Nov 21 '05 #5
Jason,

Doesn't IsDate use this same technique internally?

Kerry Moorman

"Jason Pettys" wrote:
I recommend against this method in most cases; exceptions are
resource-intensive and shouldn't really be used for raw user-data
validation. It probably wouldn't matter much on a Win Forms app, but I
would really back away from this on ASP.NET if you're expecting any
volume of traffic.

The IsDate would be a better way to go.

Jason

www.pettysconsulting.com
Armin Zingler wrote:
"romy" <ro******@Powerup1.com> schrieb
What's the easiest way to verify the user had entered a valid date ?


Call Date.Parse in a Try/Catch block. If there's no excecption the date
was valid.
Armin

Nov 21 '05 #6
I'm not sure whether IsDate uses Exceptions as the primary mechanism.
Does anyone know for sure whether IsDate uses an exception for invalid
dates (1) always, (2) sometimes, or (3) never?

If I found out that it did I wouldn't use it; here's an msdn blog that
talks about it, the best quote being, "...pretend that the throw
statement makes the computer beep 3 times, and sleep for 2 seconds. If
you still want to throw under those circumstances, go for it."

http://blogs.msdn.com/ricom/archive/.../19/44697.aspx

The feedback from Jeremy Wilson on this next page seems to indicate that
IsDate does not (or at least doesn't use it alone):

http://blogs.crsw.com/mark/archive/2005/04/06/829.aspx

If I found out that IsDate DID rely primarily on an exception for
invalid values I would use something similar to that referenced in this
next article, the idea being to catch most invalid dates without
throwing an exception:

http://searchvb.techtarget.com/vsnet...293037,00.html

Jason

www.pettysconsulting.com
Kerry Moorman wrote:
Jason,

Doesn't IsDate use this same technique internally?

Kerry Moorman

"Jason Pettys" wrote:

I recommend against this method in most cases; exceptions are
resource-intensive and shouldn't really be used for raw user-data
validation. It probably wouldn't matter much on a Win Forms app, but I
would really back away from this on ASP.NET if you're expecting any
volume of traffic.

The IsDate would be a better way to go.

Jason

www.pettysconsulting.com
Armin Zingler wrote:
"romy" <ro******@Powerup1.com> schrieb
What's the easiest way to verify the user had entered a valid date ?

Call Date.Parse in a Try/Catch block. If there's no excecption the date
was valid.
Armin

Nov 21 '05 #7
Armin,

Call Date.Parse in a Try/Catch block. If there's no excecption the date
was valid.

This is what internally iw done in IsDate

(You can check it by setting the stop on all throwed events in the debugger)

:-)

Cor
Nov 21 '05 #8
"Jason Pettys" <pe****@nospam.nospam> schrieb:
I'm not sure whether IsDate uses Exceptions as the primary mechanism. Does
anyone know for sure whether IsDate uses an exception for invalid dates
(1) always, (2) sometimes, or (3) never?


According to Lutz Roeder's Reflector, the method's implementation looks like
this:

\\\
Public Shared Function IsDate(ByVal Expression As Object) As Boolean
If (Not Expression Is Nothing) Then
If TypeOf Expression Is DateTime Then
Return True
End If
If TypeOf Expression Is String Then
Try
Dim time1 As DateTime =
DateType.FromString(CType(Expression, String))
Return True
Catch exception1 As Exception
End Try
End If
End If
Return False
End Function
///

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

Nov 21 '05 #9
Jason,

You can catch the exception that IsDate throws internally like this:

From the Debug menu choose Exceptions. Select Common Language Runtime
Exceptions. Select Break into the debugger when the exception is thrown.

Now run some code that calls IsDate with an invalid date. You should get
this message:

"A first chance exception of type 'System.FormatException' occurred in
mscorlib.dll

Additional information: The string was not recognized as a valid DateTime.
There is a unknown word starting at index 0."

So I am assuming that IsDate throws an exception internally when it is sent
an invalid date. Then IsDate catches the exception and returns False.

I guess the real proof would be to look at the IL code.

Kerry Moorman
"Jason Pettys" wrote:
I'm not sure whether IsDate uses Exceptions as the primary mechanism.
Does anyone know for sure whether IsDate uses an exception for invalid
dates (1) always, (2) sometimes, or (3) never?

If I found out that it did I wouldn't use it; here's an msdn blog that
talks about it, the best quote being, "...pretend that the throw
statement makes the computer beep 3 times, and sleep for 2 seconds. If
you still want to throw under those circumstances, go for it."

http://blogs.msdn.com/ricom/archive/.../19/44697.aspx

The feedback from Jeremy Wilson on this next page seems to indicate that
IsDate does not (or at least doesn't use it alone):

http://blogs.crsw.com/mark/archive/2005/04/06/829.aspx

If I found out that IsDate DID rely primarily on an exception for
invalid values I would use something similar to that referenced in this
next article, the idea being to catch most invalid dates without
throwing an exception:

http://searchvb.techtarget.com/vsnet...293037,00.html

Jason

www.pettysconsulting.com
Kerry Moorman wrote:
Jason,

Doesn't IsDate use this same technique internally?

Kerry Moorman

"Jason Pettys" wrote:

I recommend against this method in most cases; exceptions are
resource-intensive and shouldn't really be used for raw user-data
validation. It probably wouldn't matter much on a Win Forms app, but I
would really back away from this on ASP.NET if you're expecting any
volume of traffic.

The IsDate would be a better way to go.

Jason

www.pettysconsulting.com
Armin Zingler wrote:

"romy" <ro******@Powerup1.com> schrieb
>What's the easiest way to verify the user had entered a valid date ?
>
>

Call Date.Parse in a Try/Catch block. If there's no excecption the date
was valid.
Armin

Nov 21 '05 #10
"Cor Ligthert" <no************@planet.nl> schrieb
Armin,

Call Date.Parse in a Try/Catch block. If there's no excecption the
date was valid.

This is what internally iw done in IsDate

(You can check it by setting the stop on all throwed events in the
debugger)

:-)


Ok ok, I've read it now. :-) (sometimes we forget the simple things
(searched for TryParse first)) But, what do C# people do? That's probably
why I didn't think of IsDate. Furthermore, *if* you use IsDate you should
also use CDate instead of Date.Parse.

Armin

Nov 21 '05 #11
"Jason Pettys" <pe****@nospam.nospam> schrieb
I'm not sure whether IsDate uses Exceptions as the primary
mechanism. Does anyone know for sure whether IsDate uses an
exception for invalid dates (1) always, (2) sometimes, or (3) never?

If I found out that it did I wouldn't use it; here's an msdn blog
that talks about it, the best quote being, "...pretend that the
throw statement makes the computer beep 3 times, and sleep for 2
seconds. If you still want to throw under those circumstances, go
for it."

http://blogs.msdn.com/ricom/archive/.../19/44697.aspx

The feedback from Jeremy Wilson on this next page seems to indicate
that IsDate does not (or at least doesn't use it alone):

http://blogs.crsw.com/mark/archive/2005/04/06/829.aspx

If I found out that IsDate DID rely primarily on an exception for
invalid values I would use something similar to that referenced in
this next article, the idea being to catch most invalid dates
without throwing an exception:

http://searchvb.techtarget.com/vsnet...293037,00.html

I see three ways to convert:

- Date.Parse: Depends on regional settings and is very flexible - sometimes
too flexible as some people think.
- Date.ParseExact: If a given format is expected.
- Your own function. Maybe using the function from the last link. If you're
using regex or your own parser is up to the author.

Costs of exceptions are completely out of interest as you internally always
should work with the Date data type. As a string input is usually taken from
the user - you know, the slowest part of the chain - there is absolutely no
need to optimize this process. Much more important is that the user can be
sure that the same formats are accepted throughout the entire application.

If you have to optimize it, e.g. to process a large text file containing
dates, you still can use your own function. But in this case, Date.Parse
isn't used in most cases anyway because the date format in a file is usually
limited to an exact format or at least limited to something less than
Date.Parse can recognize.

Therefore, the first question has to be which format is to be accepted.
Depending on this, the right function must be used. If you go for
Date.Parse, there is no other way than catching the exception. Validating
the string before, to prevent Date.Parse throwing an exception is bad design
because it would have to be an exact immitation of Date.Parse's behaviour.
You would have to rely on an absolute exact documentation of Date.Parse's
behavior, and you would have to correct the parsing behavior when the
Framework's implementation changes - as it does sligthly in version 2.0,
AFAIK.

Armin

Nov 21 '05 #12
Armin

Ok ok, I've read it now. :-) (sometimes we forget the simple things
(searched for TryParse first)) But, what do C# people do? That's probably
why I didn't think of IsDate. Furthermore, *if* you use IsDate you should
also use CDate instead of Date.Parse.

Exactly. I am as well active in the dotNet general newsgroup. You understand
the discussions that has been?

One of few VisualBasic methods beside this that I like very much is the
CDate (because it converts as well very easy Database Items. The docs from
MSD say that this conversion methods are much improved comparissing with VB6
and that there is not any reason not to use them. In contrary it is advised.

By the way, there is somebody in this newsgroup active who does not agree
this with me.

:-)

Cor

Nov 21 '05 #13

"Armin Zingler">
I see three ways to convert:

System.Parse
System.Convert (ToDateTime)
CDate

:-)

Cor
Nov 21 '05 #14
"Cor Ligthert" <no************@planet.nl> schrieb

"Armin Zingler">
I see three ways to convert:
System.Parse


?
System.Convert (ToDateTime)
only calls date.parse.
CDate


That's only relevant to the programmer, not the user, above all for historic
reasons (VB6). CDate expects an object, date.parse expects a string. If you
pass as string, there's no difference to date.parse.

I wanted to show the three main levels of format limitation (strict,
flexible, user defined) rather than showing all available methods.

Armin

Nov 21 '05 #15
"Cor Ligthert" <no************@planet.nl> schrieb
Armin
Ok ok, I've read it now. :-) (sometimes we forget the simple
things (searched for TryParse first)) But, what do C# people do?
That's probably why I didn't think of IsDate. Furthermore, *if*
you use IsDate you should also use CDate instead of Date.Parse.

Exactly. I am as well active in the dotNet general newsgroup. You
understand the discussions that has been?


No, I don't read that group.
I don't ask further because it's probably been discussed already. :)
One of few VisualBasic methods beside this that I like very much is
the CDate (because it converts as well very easy Database Items. The
docs from MSD say that this conversion methods are much improved
comparissing with VB6 and that there is not any reason not to use
them. In contrary it is advised.

By the way, there is somebody in this newsgroup active who does not
agree this with me.

:-)


I think, I know him. ;-)

Armin
Nov 21 '05 #16
Armin,

Oh, if that means the same in German as Dutch

(Glad that you declared it to me, I understood you wrong)

:-)

Cor
Nov 21 '05 #17
Extracted from full quote below:
As a string input is usually taken from
the user - you know, the slowest part of the chain - there is absolutely no
need to optimize this process.
If you had a high-traffic ASP.NET site with a lot user-entered date
validation required, is there still "absolutely no need to optimize this
process"?

Jason

Armin Zingler wrote: "Jason Pettys" <pe****@nospam.nospam> schrieb
I'm not sure whether IsDate uses Exceptions as the primary
mechanism. Does anyone know for sure whether IsDate uses an
exception for invalid dates (1) always, (2) sometimes, or (3) never?

If I found out that it did I wouldn't use it; here's an msdn blog
that talks about it, the best quote being, "...pretend that the
throw statement makes the computer beep 3 times, and sleep for 2
seconds. If you still want to throw under those circumstances, go
for it."

http://blogs.msdn.com/ricom/archive/.../19/44697.aspx

The feedback from Jeremy Wilson on this next page seems to indicate
that IsDate does not (or at least doesn't use it alone):

http://blogs.crsw.com/mark/archive/2005/04/06/829.aspx

If I found out that IsDate DID rely primarily on an exception for
invalid values I would use something similar to that referenced in
this next article, the idea being to catch most invalid dates
without throwing an exception:

http://searchvb.techtarget.com/vsnet...293037,00.html

I see three ways to convert:

- Date.Parse: Depends on regional settings and is very flexible -

sometimes too flexible as some people think.
- Date.ParseExact: If a given format is expected.
- Your own function. Maybe using the function from the last link. If you're using regex or your own parser is up to the author.

Costs of exceptions are completely out of interest as you internally always should work with the Date data type. As a string input is usually taken
from
the user - you know, the slowest part of the chain - there is absolutely no need to optimize this process. Much more important is that the user can be sure that the same formats are accepted throughout the entire application.
If you have to optimize it, e.g. to process a large text file containing
dates, you still can use your own function. But in this case, Date.Parse
isn't used in most cases anyway because the date format in a file is
usually
limited to an exact format or at least limited to something less than
Date.Parse can recognize.

Therefore, the first question has to be which format is to be accepted.
Depending on this, the right function must be used. If you go for
Date.Parse, there is no other way than catching the exception. Validating
the string before, to prevent Date.Parse throwing an exception is bad
design
because it would have to be an exact immitation of Date.Parse's behaviour. You would have to rely on an absolute exact documentation of Date.Parse's
behavior, and you would have to correct the parsing behavior when the
Framework's implementation changes - as it does sligthly in version 2.0,
AFAIK.

Armin

Nov 21 '05 #18
"Jason Pettys" <pe****@nospam.nospam> schrieb
Extracted from full quote below:
As a string input is usually taken from
the user - you know, the slowest part of the chain - there is
absolutely no need to optimize this process.


If you had a high-traffic ASP.NET site with a lot user-entered date
validation required, is there still "absolutely no need to optimize
this process"?


If you have one user sitting in front, is there any reason to forbid
Try/Catch?
Armin

Nov 21 '05 #19
Armin Zingler wrote:
"Jason Pettys" <pe****@nospam.nospam> schrieb
Extracted from full quote below:
> As a string input is usually taken from
> the user - you know, the slowest part of the chain - there is
> absolutely no need to optimize this process.


If you had a high-traffic ASP.NET site with a lot user-entered date
validation required, is there still "absolutely no need to optimize
this process"?

If you have one user sitting in front, is there any reason to forbid
Try/Catch?


I don't understand your question. As I said in my first reply to the
OP: "It probably wouldn't matter much on a Win Forms app, but I would
really back away from this on ASP.NET if you're expecting any volume of
traffic."

In the latter case I would anticipate that a lot of unnecessary
exceptions would cause a noticeable performance penalty. In the former
case I think one could get by with a Try/Catch. I guess my point was
that there are cases where optimization should be a concern even when
the only validation is of user-entered data, and one should be aware of
both sides when picking how to validate dates.

Don't you agree that a developer should be aware that in some cases the
exception-based approach can be a performance problem?

Jason
Nov 21 '05 #20
"Jason Pettys" <pe****@nospam.nospam> schrieb
Armin Zingler wrote:
"Jason Pettys" <pe****@nospam.nospam> schrieb
Extracted from full quote below:

> As a string input is usually taken from
> the user - you know, the slowest part of the chain - there is
> absolutely no need to optimize this process.

If you had a high-traffic ASP.NET site with a lot user-entered
date validation required, is there still "absolutely no need to
optimize this process"?

If you have one user sitting in front, is there any reason to
forbid Try/Catch?


I don't understand your question.


Just like I didn't understand yours.
As I said in my first reply to
the OP: "It probably wouldn't matter much on a Win Forms app, but I
would really back away from this on ASP.NET if you're expecting any
volume of traffic."
I didn't know the client machine is not able to check this. Such a lot of
resources wasted!
In the latter case I would anticipate that a lot of unnecessary
exceptions would cause a noticeable performance penalty. In the
former case I think one could get by with a Try/Catch. I guess my
point was that there are cases where optimization should be a
concern even when the only validation is of user-entered data, and
one should be aware of both sides when picking how to validate
dates.

Don't you agree that a developer should be aware that in some cases
the exception-based approach can be a performance problem?


I do agree. What I explained in my previous post: If you want to use
date.parse, you must use try/catch for the reasons given. By saying "use
date.parse" I mean "permit the format(s) that date.parse permits". If you
don't use date.parse, it's up to you, of course.

Armin

Nov 21 '05 #21
Jason,

I find it a much larger problem that I cannot find how to get the
language/culture setting the client is using on the serverside.

Therefore I have probably only seen on a webpage three textboxes with day,
month, year while that is than checked using javascript. That gives as extra
(not that important) few traffic.

However if you have a very good method to get the language/culture setting
from the client on server side, than I will be much obliged.

Just my thought,

Cor
Nov 21 '05 #22
Cor,

an OT question: do you see my reply to Jason from today, 02:03 AM? When I
posted the message (and two other messages), it appeared in my OE as a new
message, but when I clicked on it, it was thriked through as if it has been
deleted from the server (and I did not delete it). As written above, this
happens to another message, but I did get a reply to it, so I think it must
have been on the server. It was a message in the thread "How to compare
objects using their typecode". I can see only one answer from me from 22:29
yesterday, but not the one from today, 02:46. Do you see still it?

Thx a lot, Cor, if you could have a look, and sorry ppl for asking here!

Armin

P.S: I also have the problem that I am told about 6 new messages in this
group (since Sunday) but when I try to download them they don't seem to
exist - then they are back again...and gone...there...gone... :( Maybe I
should reset my news reader.

Nov 21 '05 #23
Cor,

Stooop! I reset the group in the news reader and eveything seems to be fine
now. Sorry for wasting your time (if you already did ;-) )! (I should have
done this before...)

Armin

Nov 21 '05 #24
Armin,

I was starting to hanlde it, glad you messaged this (what I would expect
from you)

I don't know how fast at the moment your connection is. However some months
they had not set the retention time. The newsgroups where growing and
growing.

You understand probably what this means for dial up users.

Now it is luckily 2 months again.

Cor
Nov 21 '05 #25
"Cor Ligthert" <no************@planet.nl> schrieb
I was starting to hanlde it, glad you messaged this (what I would
expect from you)

I don't know how fast at the moment your connection is. However some
months they had not set the retention time. The newsgroups where
growing and growing.

You understand probably what this means for dial up users.

Now it is luckily 2 months again.

As I still have the problem that there are 7 new posts that disappear as
quickly as they appeared, I activated NNTP logging. From the log file I see
that there seems to be something going on on the server. Very short example
(lines received from the news server):

13:39:30 [rx] 211 9083 276748 285823 microsoft.public.dotnet.languages.vb
13:42:15 [rx] 211 29394 1 285825 microsoft.public.dotnet.languages.vb

The 3 numbers after 211 are:
9083 = approximate number of posts in the group
276748 = number of first article
285823 = number of last article

As you see in the second line (only 3 mins later) the numbers changed
totally. This happens almost each time the group is accessed. Well, let's
wait till this stops.
I write this here because others might also have problems with this group
(not with the ppl but the download ;)

Armin

Nov 21 '05 #26
Armin,

Your message as reply to Jason I see in my newsreader.
I replied it as well with a complete different text, because I find it a
long time a problem that I cannot get the used culture/language on the
client computer when he is using IE, and maybe Jason has an answer for that.

This is a part of your message
I don't understand your question.

Just like I didn't understand yours.
You know that Google is great now with these newsgroup.
This is this thread
http://groups-beta.google.com/group/...8e2533ae754cae

This is the address to it
http://groups-beta.google.com/group/...n&lr=&ie=UTF-8

Cor
Nov 21 '05 #27
"Armin Zingler" <az*******@freenet.de> schrieb:
P.S: I also have the problem that I am told about 6 new messages in this
group (since Sunday) but when I try to download them they don't seem to
exist - then they are back again...and gone...there...gone...


The same here...

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Nov 21 '05 #28
The easiest way is to use the DateTime Picker for user input to ensure he
inputs a valid date.
--
Dennis in Houston
"romy" wrote:
What's the easiest way to verify the user had entered a valid date ?

Nov 21 '05 #29

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

8
by: John V | last post by:
What kind of regular expression pattern is needed to check if URL is valid? It's enought if most of cases are covered. I have PHP 4.x. Br
7
by: - ions | last post by:
I have created a JComboBox with its Items as a list of "M" numbers ie. M1,M2,M3.......throgh too M110 (thes are the messier objects, a catolouge of deep sky objects) the user selects of of these...
67
by: Steven T. Hatton | last post by:
Some people have suggested the desire for code completion and refined edit-time error detection are an indication of incompetence on the part of the programmer who wants such features. ...
4
by: SQLScott | last post by:
I have created a VB.Net app that takes data from Visual Foxpro and inserts it into SQL Server. The problem I am running into is that I have come across records in Foxpro where the dates are as...
11
by: Bob Day | last post by:
The IsDate code below should result in False, instead it throws the exception below. Why? How do I check if a string can be converted to a date if this function does not work properly? Bob ...
4
by: Patient Guy | last post by:
Does anyone have any coding rules they follow when doing argument checking? When arguments fail during check, do you return from the call with an ambiguous return value, or do you throw...
17
by: Petyr David | last post by:
Just looking for the simplest. right now my perl script returns an error messge to the user if the date string is invalid. would like to do this before accessing the server. TX
7
by: kannushree | last post by:
i have built a program ,that checks wheteher a date is valid or not. now if i want to add date,month year (in same input) to a particular date,,how wud the logic work? it should be like dis : void...
6
by: Mike P | last post by:
How do I check for a valid datetime, where both the date and the time must be entered in the format DD/MM/YYYY HH:MM? Using Convert.ToDateTime would work even if a time is not added so I can't...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.