Hi sven
Ideally I would like to see the core of Pharo to improve.
In the past I was thinking that we could have a better “time” package but it
would become too large.
So now I would like to have
- possibility to have a nice and compact kernel for pharo internal
- nice loadable libraries such as aconcagua or others
Now the point of my email.
I would like to see some Z component such as ZTimestamp or ZUrl replace what we
have.
Would it make sense
to rename ZTimestamp as DateAndTime and put in pharo?
or to replace DateAndTime but Ztimestamp renamed Timestamp?
Now to me when I think about Date and Time I do not think about timestamp but
may be they have the same API at the end.
S
> On 27 Jan 2022, at 10:28, Sven Van Caekenberghe <s...@stfx.eu> wrote:
>
> Hi,
>
> Last year, I extended ZTimestamp with a default nanosecond precision (it
> previously had whole second precision). This makes it a more complete
> replacement for DateAndTime.
>
> https://github.com/svenvc/ztimestamp
> https://github.com/svenvc/ztimestamp/commit/de6c5a670ed0c6cb18894b4917383dd9d1dbe503
>
> The goals of ZTimestamp are to be simpler and more efficient (both faster and
> more compact). A ZTimestamp instance occupies half the space of a DateAndTime
> instance, its two slots being SmallIntegers. Back in the 32-bit days, the
> seconds since midnight field was too small for nanoseconds. Now, 64-bit is
> the default and there is enough room and no speed penalty for working with
> nanoseconds since midnight.
>
> In casual use, you won't see much of a difference, apart from the added
> detail:
>
> ZTimestamp now. "2022-01-27T09:21:20.528695Z"
>
> There are ways to convert to the older precision:
>
> ZTimestamp now truncated.
> ZTimestamp now rounded.
> ZTimestamp nowTruncated.
>
> Obviously, other methods and classes now support this added precision (like
> ZTimestampFormat).
>
> If you load or depend on tag/release v25 you get the latest version before
> this major change.
>
> If you encounter any problems please let me know.
>
> Sven
