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 