# Introducing "Time" **URL:** \ **Category:** Related Projects\ **Tags:** date\ **Created:** [February 29, 2020, 9:36pm UTC](https://forums.swift.org/t/introducing-time/34196 "2020-02-29T21:36:42Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![davedelong](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/davedelong/32/38708_2.png) [@davedelong](https://forums.swift.org/u/davedelong)\ **Post date:** [February 29, 2020, 9:36pm UTC](https://forums.swift.org/t/introducing-time/34196/1 "2020-02-29T21:36:42Z")
Today is Leap Day, so I'd like to introduce you to a new Swift package I've been working on for over 2 years: > **[GitHub - davedelong/time: Building a better date/time library for Swift](https://github.com/davedelong/time)** > > Building a better date/time library for Swift. Contribute to davedelong/time development by creating an account on GitHub. **Time** is a package that makes date and time calculations more expressive and safe in Swift. It's built on the power of Foundation's APIs, but smooths away their many rough and ambiguous edges. It relies heavily on Swift's generics to guarantee that the calculations you're performing are calendrically correct. If you'd like an overview of how it works, be sure to [check out the documentation](https://github.com/davedelong/time/tree/master/Documentation). I'm releasing it today as an `0.9.0` version. I hope you will clone it and use it in your apps! ---
**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\ **Post date:** [February 29, 2020, 10:27pm UTC](https://forums.swift.org/t/introducing-time/34196/2 "2020-02-29T22:27:28Z")
So…how do you feel about bikeshedding? ---
**Author:** ![davedelong](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/davedelong/32/38708_2.png) [@davedelong](https://forums.swift.org/u/davedelong)\ **Post date:** [February 29, 2020, 10:45pm UTC](https://forums.swift.org/t/introducing-time/34196/3 "2020-02-29T22:45:29Z")
It's a fun diversion. What's on your mind? ---
**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\ **Post date:** [February 29, 2020, 10:51pm UTC](https://forums.swift.org/t/introducing-time/34196/4 "2020-02-29T22:51:40Z")
Well first off, having read through the documentation, I’m wondering what the rationale is for choosing the spelling `clock.thisInstant()` instead of `clock.now()`. And second, I think some of the type names are not specific enough, including `Absolute`, `Value`, `Difference`, and `AbsoluteValueSequence`. ---
**Author:** ![davedelong](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/davedelong/32/38708_2.png) [@davedelong](https://forums.swift.org/u/davedelong)\ **Post date:** [February 29, 2020, 10:57pm UTC](https://forums.swift.org/t/introducing-time/34196/5 "2020-02-29T22:57:41Z")
> [@Nevin](#): > > Well first off, having read through the documentation, I’m wondering what the rationale is for choosing the spelling `clock.thisInstant()` instead of `clock.now()` . It actually has both: [https://github.com/davedelong/time/blob/master/Sources/Time/3.%20Clock/Clock%2BCurrentValues.swift#L13](https://github.com/davedelong/time/blob/master/Sources/Time/3.%20Clock/Clock%2BCurrentValues.swift#L13) `now()` is the same thing as `thisInstant()`. It has both because `now()` is the "proper" naming, but `thisInstant()` also helps it be consistent with `thisDay()`, `thisMonth()`, `thisSecond()`, etc. > [@Nevin](#): > > And second, I think some of the type names are not specific enough, including `Absolute` , `Value` , `Difference` , and `AbsoluteValueSequence` . Naming has been my #1 most difficult task with this framework. If you look on the ["Roadmap" page](https://github.com/davedelong/time/blob/master/Documentation/1-Overview/2-Roadmap.md), you'll see that I definitely want to rename `Value`, but only if I can find something better. I've spent weeks scouring sources for more definitive names for "a subset of calendrical values that may or may not be anchored to an actual calendrical point", but haven't come up with anything that really feels "better". `Difference` used to be `Delta`; I renamed it in the hopes that `Difference` would be a bit clearer. `Absolute` (and the WIP `Relative`) used to be `Anchored` and `Floating`. `AbsoluteValueSequence` is basically just derived from `Absolute`. I'm absolutely open to suggestions on better names. I'd _prefer_ names that are terms-of-art, but I have yet to find such nomenclature. ---
**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\ **Post date:** [February 29, 2020, 11:03pm UTC](https://forums.swift.org/t/introducing-time/34196/6 "2020-02-29T23:03:32Z")
Yeah, I don’t know what the types should be named, but I think the names should at least indicate that they have something to do with time. Spellings like `Value`, `Difference`, `Anchored`, and `Delta` seem too general-purpose, especially when used in an app that imports many different libraries. ---
**Author:** ![davedelong](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/davedelong/32/38708_2.png) [@davedelong](https://forums.swift.org/u/davedelong)\ **Post date:** [February 29, 2020, 11:05pm UTC](https://forums.swift.org/t/introducing-time/34196/7 "2020-02-29T23:05:14Z")
To be fair, the names are all _technically_ namespaced within the module, so we're really talking about a `Time.Value`, a `Time.Difference`, a `Time.Absolute`, etc.. But yes, in principle I agree. The current names are the "least bad" ones I've been able to come up with. 😄 ---
**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\ **Post date:** [February 29, 2020, 11:06pm UTC](https://forums.swift.org/t/introducing-time/34196/8 "2020-02-29T23:06:31Z")
Sure, you _can_ write `Time.Value`, but you don’t have to and most people won’t. So it’ll just be “`Value`” at the point of use. After all, how often do you see `Swift.Array` (or any other type) written in the wild? ---
**Author:** ![davedelong](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/davedelong/32/38708_2.png) [@davedelong](https://forums.swift.org/u/davedelong)\ **Post date:** [March 1, 2020, 12:00am UTC](https://forums.swift.org/t/introducing-time/34196/9 "2020-03-01T00:00:49Z")
FWIW, the lack of a better name for `Value` and friends is also why this is `0.9.0` and not `1.0.0`... ---
**Author:** ![hisekaldma](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/hisekaldma/32/1146_2.png) [@hisekaldma](https://forums.swift.org/u/hisekaldma)\ **Post date:** [March 1, 2020, 12:04pm UTC](https://forums.swift.org/t/introducing-time/34196/10 "2020-03-01T12:04:41Z")
This looks super interesting! From reading the documentation, I have one comment, and that’s that your usage of the term ”unsafe” seems to be at odds with how it’s generally used in Swift. ”Unsafe” in Swift generally refers to memory safety. For example, in the Standard Library `unsafe` in the name of a type, method or parameter means that Swift’s standard guarantee of memory safety no longer applies, and unless you know what you’re doing you might have memory leaks, memory corruption or even undefined behavior on your hands. You seem to be using ”unsafe” to mean that an adjustment may throw. That’s not the same. To someone accustomed to the Standard Library’s usage of ”unsafe”, it makes these adjustments look much scarier than they actually are. ---
**Author:** ![ktoso](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ktoso/32/44526_2.png) [@ktoso](https://forums.swift.org/u/ktoso)\ **Post date:** [March 2, 2020, 1:49am UTC](https://forums.swift.org/t/introducing-time/34196/11 "2020-03-02T01:49:34Z")
This looks really cool, great job! 🎉 Skimmed through the code a bit and it seems quite serious in tackling the calendar weirdnesses, that's great 🙂 The topic of time/calendars is such a complete minefield... 😓 ---
**Author:** ![Jon\_Hull](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jon_hull/32/678_2.png) [@Jon\_Hull](https://forums.swift.org/u/Jon_Hull)\ **Post date:** [March 2, 2020, 1:51am UTC](https://forums.swift.org/t/introducing-time/34196/12 "2020-03-02T01:51:46Z")
Have you considered using Time/AbsoluteTime or RelativeTime/Time instead of Value and Absolute respectively? (In my own Calendar library I have Day/Month/etc... and RelativeDay/RelativeMonth/etc...) ---
**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\ **Post date:** [March 2, 2020, 6:10am UTC](https://forums.swift.org/t/introducing-time/34196/13 "2020-03-02T06:10:03Z")
I haven‘t read the code, but I noticed some API‘s mentioned upthread. Why are some of the operations methods (e.g. `.now()`)? I believe in `Dispatch` that was a mistake that got stuck on us forever. Could we change those into properties? The parentheses are really redundant. ---
**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\ **Post date:** [March 2, 2020, 7:21am UTC](https://forums.swift.org/t/introducing-time/34196/14 "2020-03-02T07:21:35Z")
I'd push back against this one. IMO properties ought to produce the same value when accessed repeatedly unless there's some intervening (imperative) logic. ---
**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\ **Post date:** [March 2, 2020, 7:35am UTC](https://forums.swift.org/t/introducing-time/34196/15 "2020-03-02T07:35:19Z")
Fair point. I can‘t remember a case where this wasn‘t true either. 🤔 ---
**Author:** ![davedelong](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/davedelong/32/38708_2.png) [@davedelong](https://forums.swift.org/u/davedelong)\ **Post date:** [March 2, 2020, 4:44pm UTC](https://forums.swift.org/t/introducing-time/34196/16 "2020-03-02T16:44:54Z")
There's been some discussion about this in one of the issues on GH: [All zero-argument methods that return a value should be computed properties instead · Issue #7 · davedelong/time · GitHub](https://github.com/davedelong/time/issues/7) ---
**Author:** ![davedelong](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/davedelong/32/38708_2.png) [@davedelong](https://forums.swift.org/u/davedelong)\ **Post date:** [March 2, 2020, 4:46pm UTC](https://forums.swift.org/t/introducing-time/34196/17 "2020-03-02T16:46:18Z")
> [@hisekaldma](#): > > From reading the documentation, I have one comment, and that’s that your usage of the term ”unsafe” seems to be at odds with how it’s generally used in Swift. > > ”Unsafe” in Swift generally refers to memory safety. For example, in the Standard Library `unsafe` in the name of a type, method or parameter means that Swift’s standard guarantee of memory safety no longer applies, and unless you know what you’re doing you might have memory leaks, memory corruption or even undefined behavior on your hands. > > You seem to be using ”unsafe” to mean that an adjustment may throw. That’s not the same. To someone accustomed to the Standard Library’s usage of ”unsafe”, it makes these adjustments look much scarier than they actually are. If you have alternative naming suggestions, I'd love to hear them. 🙂 ---
**Author:** ![hisekaldma](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/hisekaldma/32/1146_2.png) [@hisekaldma](https://forums.swift.org/u/hisekaldma)\ **Post date:** [March 2, 2020, 5:58pm UTC](https://forums.swift.org/t/introducing-time/34196/18 "2020-03-02T17:58:58Z")
> [@davedelong](#): > > If you have alternative naming suggestions, I'd love to hear them. 🙂 The name that comes to mind is `FailableAdjustment`, since that’s essentially what they are: adjustments that can fail. I guess you could argue that ”failable” also means that they should return nil instead of throw, since that’s what failable means when we talk about initializers. I don’t have enough experience with the API yet to know if that would make sense. Regardless, something ”failable” that doesn't return nil seems to me a lesser sin than something ”unsafe” that’s completely memory safe. ---
**Author:** ![davedelong](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/davedelong/32/38708_2.png) [@davedelong](https://forums.swift.org/u/davedelong)\ **Post date:** [March 2, 2020, 6:04pm UTC](https://forums.swift.org/t/introducing-time/34196/19 "2020-03-02T18:04:59Z")
> [@hisekaldma](#): > > something ”failable” that doesn't return nil seems to me a lesser sin than something ”unsafe” that’s completely memory safe. There are different kinds of "safe" in Swift. There's the memory safety you've brought up, but there's also type safety, the safety of exhaustiveness checking, etc. It's true that "unsafe" has typically only referred to memory safety, but given then other kinds of "safety" guarantees that Swift provides, it seems reasonable to me to use the same term here. However, I'm absolutely willing to change it if we can come up with a superior name. 🙂 ---
**Author:** ![Lantua](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lantua/32/8868_2.png) [@Lantua](https://forums.swift.org/u/Lantua)\ **Post date:** [March 2, 2020, 6:15pm UTC](https://forums.swift.org/t/introducing-time/34196/20 "2020-03-02T18:15:42Z")
We can just drop `Unsafe`. `throws`-ness signals plenty enough of that. And while I agree that there are multiple kinds of safety in swift, `Unsafe` is still used exclusively for memory safety. [Next page](https://forums.swift.org/t/introducing-time/34196.md?page=2)