Hi Stef, ZTimestamp is meant to be used as an alternative/replacement for DateAndTime. That means that if you need a timestamp representation for which you would normally use DateAndTime, you can use now ZTimestamp. It is more efficient as it is half as large in memory and most operations are faster. It is also simpler. However, it is not 100% the same. It does not hold timezone information and is always in UTC, not your local timezone. The idea is that you only convert to/from another timezone when you need to, when reading/writing or in a UI. There is full support for that, but it is a specific approach. I am not advocating that ZTimestamp should replace DateAndTime in the standard image. I just would like people to be aware that there are alternatives with nice properties (including example based formatting/parsing and full timezone support, both in separate classes). Sven

On 30 Jan 2022, at 13:36, stephane ducasse <stephane.ducasse@inria.fr> wrote:

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 <sven@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/de6c5a670ed0c6cb18894b4917383dd9...

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