-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is dround bugged or just confusing? (now with specific timezone) #158
Comments
I think the confusion is that you expect this to happen:
when in fact this happens:
IOW, the rounding happens first (in UTC time), then is converted to Berlin time. However, in the last example with your timestamp I get:
That is 02:24:33 instead of 00:24:33, or in clocks: an hour ahead instead of behind. |
Thank you very much for this fast response. Now everything does make a lot more sense! And with your explanation I can suddenly see this detail in the man page entry of And you are also right regarding my last example. I just added it later for some kind of completion and may have made a mistake while recording. But this isn't that important for my actual use case. Actually I want to determine the next occurrence of a specific time (hours:minutes) on a specific day of the month from the present point in time.
This looked okay to me in the first place, but after your explanation I'm not sure if this is the right way to do it. Ultimately I would like to know if there is a "cleaner" way to accomplish this specific rounding with only dateutils onboard tools? I would like to leave out the command substitution |
Yes-ish. A timestamp in dateutils as such is zone-less, by which I mean it doesn't carry a timezone designation (as in, say, the SQL type DATETIMEOFFSET or DATETIMETZ). So if you feed it a textual string dateutils is just doing its thing but if you invoke timezone stuff (--zone for instance), it's going to assume the timestamp is UTC (or sometimes TAI) by default. You can even change this assumption using --from-zone.
I already showed you. You could do:
using pipes, and the "zoned" timestamp in ISO8601 format. Or if you want it in Berlin time explicitly anywhere in the world:
dateutils allows reading timestamps from stdin if not specified. The output shall be exactly what you want. The only caveat of not being aware of the timezone is that you may round to forbidden or ambiguous timestamps. Berlin time (currently) has an hour missing in March (never on the 15th though), and a duplicate hour in October (also currently never on the 15th). |
Hello,
I wanted to use the special
now
ofdateutils.dround
with a specific time zone (-z Europe/Berlin
), but after testing it a little bit and comparing the results withdate +'%FT%T'
as the timestamp (which should be the same as timezonednow
according to my understanding) I either discovered a bug or confused the hell out of me and didn't understand howdround
is working in the first place.Could you please explain to me why the results are different, even though the timestamps are initially the same?
This is what I've done:
The "rounded" times without any
RNDSPEC
(so the actual current time)RNDSPEC=1s
now
anddate
print the (imho) correct next occuring time with01
in the seconds field.RNDSPEC=1m
now
anddate
both print the (imho) correct next occuring time with01
in the minute field.RNDSPEC=1h
now
prints a time with03
in the hour field even though1h
was specified. It also didn't change the day even though the current time isT01:24:33
and therefore nextT01:**:**
can only occur the next day.The output of
date
on the other hand is what I expected from thisRNDSPEC
.RNDSPEC=1d
now
prints a time with02
in the day field even though1d
was specified.The output of
date
on the other hand is what I expected from thisRNDSPEC
.RNDSPEC=1mo
now
prints a (imho) correct next occuring date with01
in the month field. But it shifts the time back one hour even though only1d
was specified.The output of
date
on the other hand is what I expected from thisRNDSPEC
.The text was updated successfully, but these errors were encountered: