Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Tcl clock arithmetic question

105 views
Skip to first unread message

Jeff Godfrey

unread,
Jul 17, 2015, 10:14:27 AM7/17/15
to
Hi All,

I'm sure this is a simple problem, but so far I haven't found the proper Tcl-foo to resolve it (using Tcl 8.6.4 on Windows).

I simply want to calculate the number of minutes that have passed in the current year.

Something like this is close:

expr {([clock seconds] - [clock scan "2015-01-01 00:00:00" -format "%Y-%m-%d %H:%M:%S"]) / 60}

The trick is that I want the minutes calculated directly from the current system time - ignoring any possible DST shift.

The above produces a result that's 60 minutes off (I assume due to DST).

I've tried a number of variations on the above, including "-gmt 1", "-timezone :UTC", etc - but I just can't get the results to work out.

In case it's helpful, I'm comparing my results to that shown here:

http://www.timeanddate.com/date/durationresult.html

...which seems to return the results I expect.

I thought that [clock seconds] return a value based on GMT, so it made since that I needed to shift my comparison date into GMT also, but so far, no luck.

Thanks for any advice.

Jeff

Robert Heller

unread,
Jul 17, 2015, 12:57:59 PM7/17/15
to
You might try:

[clock scan now -gmt 1]

>
> Thanks for any advice.
>
> Jeff
>

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services

Jeff Godfrey

unread,
Jul 17, 2015, 2:11:50 PM7/17/15
to
On Friday, July 17, 2015 at 11:57:59 AM UTC-5, Robert Heller wrote:
> You might try:
>
> [clock scan now -gmt 1]

Thanks, but no luck.

[clock seconds]
[clock scan now]
[clock scan now -gmt 1]

all seem to return the same value...

Rich

unread,
Jul 17, 2015, 2:22:56 PM7/17/15
to
Jeff Godfrey <jeffgo...@gmail.com> wrote:
> Hi All,

> I'm sure this is a simple problem, but so far I haven't found the
> proper Tcl-foo to resolve it (using Tcl 8.6.4 on Windows).

> I simply want to calculate the number of minutes that have passed in
> the current year.

> Something like this is close:

> expr {([clock seconds] - [clock scan "2015-01-01 00:00:00" -format "%Y-%m-%d %H:%M:%S"]) / 60}

> The trick is that I want the minutes calculated directly from the
> current system time - ignoring any possible DST shift.

Then you have to give a -timezone parameter to clock scan to inform it
if that fact. Otherwise, it defaults to interpreting in your local
timezone.

> The above produces a result that's 60 minutes off (I assume due to
> DST).

Yes, it is

> I've tried a number of variations on the above, including "-gmt 1",
> "-timezone :UTC", etc - but I just can't get the results to work out.

> In case it's helpful, I'm comparing my results to that shown here:
> http://www.timeanddate.com/date/durationresult.html
> ...which seems to return the results I expect.

Note, why do you believe this webpage is correct, but feel Tcl's clock
is wrong? What evidence do you have that the webpage is more likely to
be correct?

> I thought that [clock seconds] return a value based on GMT, so it
> made since that I needed to shift my comparison date into GMT also,
> but so far, no luck.

No, you have to manually "undo" your timezone offset for summer time
from your clock scan.

This produces the correct value from Tcl that matches the value from
the webpage (which provides evidence that both are likely correct)
(note, I'm in EDT now, so I had to apply the EDT offset to the scan).

expr {([clock seconds] - [clock scan "2015-01-01 00:00:00" -format "%Y-%m-%d %H:%M:%S" -timezone -0400]) / 60}

Jeff Godfrey

unread,
Jul 17, 2015, 3:35:09 PM7/17/15
to
On Friday, July 17, 2015 at 1:22:56 PM UTC-5, Rich wrote:
> Jeff Godfrey wrote:
>
> Note, why do you believe this webpage is correct, but feel Tcl's clock
> is wrong? What evidence do you have that the webpage is more likely to
> be correct?

Because the webpage provides a break down like this:

197 days, 14 hours, 26 minutes and 25 seconds

...in addition to other formats...

Which is 1) easy to verify that it's the correct local time (2:26 pm), 2) is easy to manually calculate the necessary results from, and 3) those manually calculated results match the results presented by the website - but are 60 minutes different than the values returned by Tcl.
>
> > I thought that [clock seconds] return a value based on GMT, so it
> > made since that I needed to shift my comparison date into GMT also,
> > but so far, no luck.
>
> No, you have to manually "undo" your timezone offset for summer time
> from your clock scan.
>
> This produces the correct value from Tcl that matches the value from
> the webpage (which provides evidence that both are likely correct)
> (note, I'm in EDT now, so I had to apply the EDT offset to the scan).
>
> expr {([clock seconds] - [clock scan "2015-01-01 00:00:00" -format "%Y-%m-%d %H:%M:%S" -timezone -0400]) / 60}

OK, but how would I do this generically - from any local system clock anywhere in the world (always ignoring DST offsets)?

Again, it's simple in concept. I just want to know the total number of minutes from the beginning of the year - according to the time presented by the local system clock. Nothing more.

Don Porter

unread,
Jul 17, 2015, 3:55:24 PM7/17/15
to

>> Note, why do you believe this webpage is correct, but feel Tcl's
>> clock is wrong? What evidence do you have that the webpage is more
>> likely to be correct?
>
> Because the webpage provides a break down like this:
>
> 197 days, 14 hours, 26 minutes and 25 seconds
>
> ...in addition to other formats...
>
> Which is 1) easy to verify that it's the correct local time (2:26
> pm), 2) is easy to manually calculate the necessary results from, and
> 3) those manually calculated results match the results presented by
> the website - but are 60 minutes different than the values returned
> by Tcl.

But that's not correct!

If you are in a zone where DST is in use now, but isn't in use on Jan 1,
then 2:26pm ought not be .... 14 hours, 26 minutes.... since the
turning of the calendar. You Spring Forward, so you set your local
clock to read 2:26pm even though elapsed time would only account
for 1:26pm.

I believe in this case Tcl's giving you the right answer and you're
comparing against an improper standard.

--
| Don Porter Applied and Computational Mathematics Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|

Rich

unread,
Jul 17, 2015, 4:26:44 PM7/17/15
to
Jeff Godfrey <jeffgo...@gmail.com> wrote:
> On Friday, July 17, 2015 at 1:22:56 PM UTC-5, Rich wrote:
> > Jeff Godfrey wrote:
> >
> > Note, why do you believe this webpage is correct, but feel Tcl's clock
> > is wrong? What evidence do you have that the webpage is more likely to
> > be correct?

> Because the webpage provides a break down like this:

> 197 days, 14 hours, 26 minutes and 25 seconds

> ...in addition to other formats...

> Which is 1) easy to verify that it's the correct local time (2:26 pm), 2) is easy to manually calculate the necessary results from, and 3) those manually calculated results match the results presented by the website - but are 60 minutes different than the values returned by Tcl.
> >
> > > I thought that [clock seconds] return a value based on GMT, so it
> > > made since that I needed to shift my comparison date into GMT also,
> > > but so far, no luck.
> >
> > No, you have to manually "undo" your timezone offset for summer time
> > from your clock scan.
> >
> > This produces the correct value from Tcl that matches the value from
> > the webpage (which provides evidence that both are likely correct)
> > (note, I'm in EDT now, so I had to apply the EDT offset to the scan).
> >
> > expr {([clock seconds] - [clock scan "2015-01-01 00:00:00" -format "%Y-%m-%d %H:%M:%S" -timezone -0400]) / 60}

> OK, but how would I do this generically - from any local system clock
> anywhere in the world (always ignoring DST offsets)?

By asking [clock]:

% clock format [clock seconds] -format %z
-0400

This bit from the clock manpage describes what is going on:

If a format string lacks a %z or %Z format group, it is possible for
the time to be ambiguous because it appears twice in the same day,
once without and once with Daylight Saving Time. If this situation
occurs, the first occurrence of the time is chosen. (For this
reason, it is wise to have the input string contain the time zone
when converting local times. This caveat does not apply to UTC
times.)


> Again, it's simple in concept. I just want to know the total number
> of minutes from the beginning of the year - according to the time
> presented by the local system clock. Nothing more.

Rolling the above together it works:

expr {([clock seconds] - [clock scan "2015-01-01 00:00:00" \
-format "%Y-%m-%d %H:%M:%S" \
-timezone [clock format [clock seconds] -format %z]]) / 60}

Jeff Godfrey

unread,
Jul 17, 2015, 4:46:42 PM7/17/15
to
On Friday, July 17, 2015 at 2:55:24 PM UTC-5, Don Porter wrote:
> >> Note, why do you believe this webpage is correct, but feel Tcl's
> >> clock is wrong? What evidence do you have that the webpage is more
> >> likely to be correct?
> >
> > Because the webpage provides a break down like this:
> >
> > 197 days, 14 hours, 26 minutes and 25 seconds
> >
> > ...in addition to other formats...
> >
> > Which is 1) easy to verify that it's the correct local time (2:26
> > pm), 2) is easy to manually calculate the necessary results from, and
> > 3) those manually calculated results match the results presented by
> > the website - but are 60 minutes different than the values returned
> > by Tcl.
>
> But that's not correct!
>
> If you are in a zone where DST is in use now, but isn't in use on Jan 1,
> then 2:26pm ought not be .... 14 hours, 26 minutes.... since the
> turning of the calendar. You Spring Forward, so you set your local
> clock to read 2:26pm even though elapsed time would only account
> for 1:26pm.
>
> I believe in this case Tcl's giving you the right answer and you're
> comparing against an improper standard.

Thanks. While I'm sure you're right.... Again - I don't care about any DST offsets. Truth be told, I'm trying to *match* the results of an algorithm being used in another application that knows nothing about DST.

That algo simply takes the current date/time from the system clock and calculates the result based on the number of days in each month that have already passed (accounting for leap year) and the number of days, hours, and minutes that have passed in the current month.

I realize this is an overly simplified version of delta time and one that's not absolutely accurate. However, that doesn't matter. What does matter is that my results must match the results of the other application given the same local date/time value.

I can certainly just code my own function to return the result I want. I mean, it's rather simple. I just figured there was some way to coerce the Tcl clock command into doing it for me. Maybe that's not the case, though I find that surprising.

Jeff Godfrey

unread,
Jul 17, 2015, 4:51:29 PM7/17/15
to
On Friday, July 17, 2015 at 3:26:44 PM UTC-5, Rich wrote:
>
> Rolling the above together it works:
>
> expr {([clock seconds] - [clock scan "2015-01-01 00:00:00" \
> -format "%Y-%m-%d %H:%M:%S" \
> -timezone [clock format [clock seconds] -format %z]]) / 60}

Ah, yes, that does seem to be the ticket. I just couldn't figure out how to get proper DST offset. I'll play with that, but it looks like exactly what I need.

Thanks for your assistance.

Gerald W. Lester

unread,
Jul 17, 2015, 5:17:47 PM7/17/15
to
Well, you could specify both times with a timezone of GMT. Get the delta
seconds and divide by 60.

--
+------------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald...@kng-consulting.net |
+------------------------------------------------------------------------+

Jeff Godfrey

unread,
Jul 17, 2015, 6:23:13 PM7/17/15
to
On Friday, July 17, 2015 at 4:17:47 PM UTC-5, Gerald W. Lester wrote:
>
> Well, you could specify both times with a timezone of GMT. Get the delta
> seconds and divide by 60.

Sure, that's exactly what I thought too. Though, I was never able to work out a method that seemed to work as expected.

If you have an example, that'd be great.

Thanks.

Gerald W. Lester

unread,
Jul 19, 2015, 1:53:05 PM7/19/15
to
set ts1 [clock scan $date1 -format "%Y-%m-%d %H:%M:%S" -gmt yes]
set ts2 [clock scan $date2 -format "%Y-%m-%d %H:%M:%S" -gmt yes]
set deltaMinutes [expr {abs($ts2 - $ts1) / 60.0}]

Jeff Godfrey

unread,
Jul 19, 2015, 6:05:06 PM7/19/15
to
On Sunday, July 19, 2015 at 12:53:05 PM UTC-5, Gerald W. Lester wrote:
> set ts1 [clock scan $date1 -format "%Y-%m-%d %H:%M:%S" -gmt yes]
> set ts2 [clock scan $date2 -format "%Y-%m-%d %H:%M:%S" -gmt yes]
> set deltaMinutes [expr {abs($ts2 - $ts1) / 60.0}]

Ah, yeah - that works as needed too. Thanks for the additional input.

0 new messages