Hello, I’m looking to get the current (date)time and add one hour to it.
Its not clear going through Io.Clock, Io.Duration, Io.Timeout, and Io.Timestamp.
Whats the simplest way to:
const start = // get current time
const end = // add 1 hour to it
print("Start: {any} End: {any}", .{start, end});
?
You need an Io implementation, and only Threaded is reasonably complete at this moment.
The Io interface is changing very rapidly. But as of this second, the way to do it is:
var t: std.Io.Threaded = .init_single_threaded;
const io = t.io();
const now = try io.vtable.now();
const one_hour : std.Io.Duration = .fromSeconds(60 * 60);
const now_plus_one_hour = now.addDuration(one_hour);
You can also use calls to “low level” C functions, at least for now (while these things are being reworked). Not necessarily the best way to do it, but it is always a last resort. So, something like (again, this is C code):
time_t seconds = time(0);
seconds += 1 * 60 * 60;
zeit can do that.
const std = @import("std");
const zeit = @import("zeit");
pub fn main() !void {
const allocator = std.heap.page_allocator;
var env = try std.process.getEnvMap(allocator);
defer env.deinit();
const local = try zeit.local(allocator, &env);
const now = try zeit.instant(.{});
const now2 = try now.add(.{
.hours = 1,
});
const time = now2.time();
var buffer: [100]u8 = undefined;
var writer = std.Io.Writer.fixed(&buffer);
try time.strftime(&writer, "%Y-%m-%d %H:%M:%S %Z");
var buffer2 = buffer[0..writer.end];
std.debug.print("{s}\n", .{buffer2}); // UTC
const now3 = now2.in(&local);
const time2 = now3.time();
writer = std.Io.Writer.fixed(&buffer);
try time2.strftime(&writer, "%Y-%m-%d %H:%M:%S %Z");
buffer2 = buffer[0..writer.end];
std.debug.print("{s}\n", .{buffer2}); // local
}
Thanks for linking it!
Surely making a library like that is a lot of work, and I’m not trying to downplay the effort put in by the contributors, but I have a few hard requirements - one of which is not using any third party library. My thinking is that if its part of the application then it needs to be worked on, not simply imported. I like Zig to the extent that I dont want to offload any work I can do using it.
Another downside is that libraries are likely (and rightly so) at a point release. I’m aiming to be as close to master as possible - especially to PRs labelled with ‘breaking’ and ‘release notes’. Incorporating a third party library would mean that I would have to watch two things instead of just Zig - and the speed at which Zig is moving, it would take a lot out of a person to do this. And also having a working project will be very tough.
The main thing is that for the stage Zig is in, third party libraries should not be promoted so that:
end users understand exactly whats going on instead of working on an abstraction
more users on the master branch means more bug reports which will make Zig even more solid
agency and ownership - using dependencies reduces both and also defeats the purpose of being an early adopter
i strongly disagree, but then again, i would, being a co-maintainer of the Lua bindings for Zig, wouldn’t I. Like many if not most projects, Ziglua follows master but we tend to rely on PRs and issues to make sure we’re paying attention to when master breaks us.
Zig is a great language for using dependencies, imo. It’s not Rust or Javascript. Typically you can read the code you’re calling into. Your argument against libraries also surely extends to std verbatim.
It’s fun to own your whole codebase, to be sure, but it’s also fun to write useful code rather than reinvent the wheel.
related: State of datetime handling in Zig?
I’ve took up the task of trying to track Zig master more closely with FObersteiner/zdt: Datetime, Timezones and Durations in Zig - Codeberg.org recently, and all I can say is this can be a big adventure. Not to depreciate Zig in any way, but you have to know what you’re up to, especially since “documentation” for the most recent changes means “read source and git diffs”.
So in principle, I’m with you on this one. Datetime handling can be so fundamental, you’d want to have it in std. I’m writing this despite having my own third party dt lib 
- And years of experience with using Python (dt as part of std, timezone not for a long time - big mess!) and go (dt + timezones as part of std - great!).
You could also use std.Io.Clock.real.now(io), to get a Timestamp, no need to dive into the vtable.
You could also use
std.Io.Clock.real.now(io), to get a Timestamp, no need to dive into the vtable.
This fits in well with the another post today Simple timestamp lib to record timestamp in logs with millisecond precision (and another linked post in it Format timestamp into ISO 8601 strings).
i strongly disagree, but then again, i would, being a co-maintainer of the Lua bindings for Zig, wouldn’t I. Like many if not most projects, Ziglua follows master but we tend to rely on PRs and issues to make sure we’re paying attention to when master breaks us.
Nothing against libraries, but I wish there are more applications with concrete use cases and are as visible as their corresponding libraries.
I would look at those applications and see how I can incorporate them to my use case. After I get my project working it may suck, but I can work towards giving it the functionality of a library or an application which has all the bells and whistles, i.e., there’s scope for craft.
Dependencies have a way of creeping in - in the beginning its going to be just one library, after a while another, and so on. If I take this approach, I will have essentially thrown in the towel at some stage, and be left duct taping dependencies to have a project working. This reflects poorly on me because I didn’t end up doing much and what I did doesn’t look good.
It’s fun to own your whole codebase, to be sure, but it’s also fun to write useful code rather than reinvent the wheel.
I’m not using datetime yet so I’ll give a different example - CLI. All popular libraries existed before I began working on my projects. I’m using the below features of the standard library:
ArgIterator and while loop to go through command line arguments, StaticStringMap and enum to “register” actions, and a struct containing switch, if, and else to parse and validate them.
I could have used a library, but glad I didn’t because I really enjoyed taking this approach. Even if its not as good as using a library, I’d use the standard library ten times out of ten.
No reinvention here and I also dont think approaching datetime using the above linked posts is reinvention.
Your argument against libraries also surely extends to
stdverbatim.
100%. My projects will never have a dependency other than the standard library. They may end up being verbose but thats fine. I hope std remains juicy like main 
Thanks for pointing out the lib I did was pre Io refactor (0.16) two weeks ago the initial version will use the Io implementation if one available
They don’t creep, you invite them in each time. Inviting one of them in doesn’t mean you can’t stop inviting more of them.
They meant that your rejection of libraries means that you should also reject the std library.
They don’t creep, you invite them in each time. Inviting one of them in doesn’t mean you can’t stop inviting more of them.
Correct, I’ve mentioned that no external dependency will end up in any of my projects for this reason.
They meant that your rejection of libraries means that you should also reject the std library.
Misunderstood it. I just want to reject external libraries, not the standard library.
Sorry, I think there is a language problem and I should not have used a double negative. What I meant to say is: You do not have to keep adding dependencies. If you find one great library that you really need, perhaps that will be your only dependency. There is no reason to be rigid on this. But I accept your decision.
there still is a difference between depending on std and 3rd party libraries, especially in a Zig-context. If you only depend on std, it’s only your code you need to adjust to changes in std. If you depend on 3rd party libs that also depend on std, you rely on them being updated as well. Then again, there are nuances to this; in the open source domain, you might fork the dependency, contribute to it or copy relevant parts to your own code (assuming proper attribution / licensing allows this). So making this a black/white thing won’t help I think. See what works best for your project and decide.
I agree with this.
In 0.15.2 there is a directory.walker() function that I could use in my code, but ended up writing my own recursive function because of all unnecessary functionality the walker() was having that I did not need. For that particular use case, my recursive function ended up being more efficient.