Time comment trivia

[prl]

The code in lib/dvb/dvbtime.cpp tests for the system time being valid with:

Code: Select all

		if ( now < 1072224000 ) // 01.01.2004

The comment there isn't correct. The time value being tested is actually:
(2004-1970)*365*24*60*60 = 1072224000

That is in fact 00:00:00 24 Dec 2003 UTC, not 00:00:00 1 Jan 2004 UTH.

00:00:00 1 Jan 2004 UTC is 1075593600.

I wouldn't bother normally, it's still a reasonable test for the clock having been set to a sensible value, but I want to use the same value as in dvbtime.cpp to test for the clock being set in fixes for bugs 588 & 589, and have a comment that refers back to dvbtime.cpp, like:

Code: Select all

		if time() < 1072224000:  # 01.01.2004, as in dvb/dvbtime.cpp

So, should I:

• propagate the incorrect comment (or Unix time value, depending on how you look at it);
• have the comment in the changes no longer match the code it refers back to;
• have the Unix time in the changes different from the dvbtime.cpp code, but still refer to the same date;
• fix the Unix time value to match the comment; or
• fix the comment to match the Unix time?

I intend making the changes available to the OpenViX folk, so if they accept them, the changes should not cause any later upstream merge problems.

When code and comments disagree, both are probably wrong.

[peteru]

00:00:00 1 Jan 2004 UTC is 1075593600.

No it isn't. You are a month out!

date -u --date='@1075593600'
Sun Feb 1 00:00:00 UTC 2004

It should be 1072915200

My preference would be to change the value to match the comment and then use the correct value.

If the value forms a part of an API (i.e. it needs to match in various parts of the code), then an even better approach would be to export it as a public constant. Not sure if it's worth the effort in the grand scheme of things.

[prl]

00:00:00 1 Jan 2004 UTC is 1075593600.

No it isn't. You are a month out!
...

You're right! I forgot that localtime months start at 0, and then didn't notice the Feb when I converted it back

[prl]

...
If the value forms a part of an API (i.e. it needs to match in various parts of the code), then an even better approach would be to export it as a public constant. Not sure if it's worth the effort in the grand scheme of things.

Currently the 1072224000 is used twice in dvbtime.cpp and nowhere else. Since it's used twice in dvbtime.cpp anyway, I think I may add a public constant.

I think I'm going to need to use it in another C++ file anyway.

[IanSav]

Hi Prl,

I would advise you make the code and the comment match. If possible keep the code and comment consistent in each usage.

Making the value a public constant would improve uniformity. Perhaps add comments to remind future coders to be careful about changing the code so to ensure that all usage of the constant remains functional.

Regards,
Ian.

[prl]

The code is currently:

Code: Select all

class eDVBLocalTimeHandler: public Object
{
	...
public:
	...
	enum { timeOK = 1072915200 }; // 1.1.2004 - system time can be assumed to be OK if >= timeOK
	...
};

in dvbtime.cpp:

Code: Select all

		if ( now < timeOK ) // 01.01.2004

(new) in servicedvb.cpp:

Code: Select all

	else if(now < eDVBLocalTimeHandler::timeOK && !m_timehandler_conn.connected())  // time < 1.1.2004

There will be similar usage where I use it in the Python code.

[IanSav]

Hi,

When are the code blocks going to be fixed?

Regards,
Ian.

[prl]

No idea.

[IanSav]

Hi Prl,

No idea.

I asked because I like to learn from / follow your coding style and the code above looks bad (one messy long line) on my browser window.

Regards,
Ian.

[prl]

Hi Prl,

No idea.

I asked because I like to learn from / follow your coding style and the code above looks bad (one messy long line) on my browser window.
...

I'm not sure that the style's offering much to emulate. I'm torn between using an enum (as in my post) or a static const member for the constant.

[IanSav]

Hi Prl,

That's fine. You know Python better than I so there is always a chance to learn more if can read your code blocks on the forum.

Regards,
Ian.

[prl]

...
That's fine. You know Python better than I so there is always a chance to learn more if can read your code blocks on the forum.
...

Those particular examples are C++, not Python.

[IanSav]

Hi Prl,

Those particular examples are C++, not Python.

Yes, but this is more about the forum formatting being broken. All the code blocks aren't working.

Regards,
Ian.

[prl]

Yes, but there's a published workaround.

[IanSav]

Hi Prl,

Yes, but there's a published workaround.

It is about time that this, and the other bugs, were fixed for everyone.

Regards,
Ian.

[peteru]

Yes, but there's a published workaround.

It is about time that this, and the other bugs, were fixed for everyone.

I made an offer to WizHQ to fix the broken CSS style code by applying the equivalent to the Stylish script modifications to the server end CSS files. The only catch is that in order for me to be able to fix the problems, I would need full access to the hosting account, so that I can edit the server side files. I have not been given access and as far as I can tell, WizHQ has not engaged their web contractor to apply such fixes. Your best bet to have this fixed is to get in touch with WizHQ. In the meantime, the Stylish script will make the forums a bit more usable.

[peteru]

I'm torn between using an enum (as in my post) or a static const member for the constant.

A properly typed static constant, in my opinion, is slightly better style because you get the benefits of strong typing. Not so much with an anonymous enum.

[prl]

I'm torn between using an enum (as in my post) or a static const member for the constant.

A properly typed static constant, in my opinion, is slightly better style because you get the benefits of strong typing. Not so much with an anonymous enum.

Yes. Downside of the static const class member is that it's instantiated as a variable (or at least an lvalue); the enum is a compile-time constant. But I tend to agree that the strong typing of the static const is enough to outweigh the small efficiency gain of the enum, especially here where the value isn't accessed very often.