Hi All, how does one produce a nice timestamp, simply date and time as in 7/7/2016 09:19:38 Trivial, right? So Date today mmddyyyy, ' ', Time now print24 '7/7/2016 09:22:40.914' .914, ah, nanos. How useful. Let's get rid of them. No nanos: accessor so Date today mmddyyyy, ' ', (Time now nanos: 0) print24 => MNU but there's a seconds accessor, so Date today mmddyyyy, ' ', (Time now seconds: Time now seconds; print24) '7/7/2016 00:00:41 ?? So seconds: is private, and isn't the dual of Time seconds: Time seconds ^ self second Time second ^ self asDuration seconds Duration seconds "Answer the number of seconds the receiver represents." ^seconds rem: SecondsInMinute Looks broken to me. Personally I think print24 should not print sub seconds. cc'ing to Pharo because I want this timestamp to be the same in both dialects for a profiling tool we want to use in both dialects. _,,,^..^,,,_ best, Eliot
On 07 Jul 2016, at 18:33, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
how does one produce a nice timestamp, simply date and time as in
7/7/2016 09:19:38
Trivial, right?
I understand that you want it 'nice and clean', but the above is not precise (no TZ) and confusing (is it M/D/YYYY or D/M/YYYY ?). Going more in the ISO direction is better (more universal), IMHO. DateAndTime now rounded => "2016-07-07T18:45:12+02:00"
So
Date today mmddyyyy, ' ', Time now print24 '7/7/2016 09:22:40.914'
.914, ah, nanos. How useful. Let's get rid of them. No nanos: accessor so
Date today mmddyyyy, ' ', (Time now nanos: 0) print24 => MNU
but there's a seconds accessor, so
Date today mmddyyyy, ' ', (Time now seconds: Time now seconds; print24) '7/7/2016 00:00:41
?? So seconds: is private, and isn't the dual of Time seconds:
Time seconds ^ self second Time second ^ self asDuration seconds Duration seconds "Answer the number of seconds the receiver represents." ^seconds rem: SecondsInMinute
Looks broken to me.
Personally I think print24 should not print sub seconds.
cc'ing to Pharo because I want this timestamp to be the same in both dialects for a profiling tool we want to use in both dialects. _,,,^..^,,,_ best, Eliot
Hi Sven,
On Jul 7, 2016, at 9:47 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 07 Jul 2016, at 18:33, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
how does one produce a nice timestamp, simply date and time as in
7/7/2016 09:19:38
Trivial, right?
I understand that you want it 'nice and clean', but the above is not precise (no TZ) and confusing (is it M/D/YYYY or D/M/YYYY ?).
Going more in the ISO direction is better (more universal), IMHO.
DateAndTime now rounded => "2016-07-07T18:45:12+02:00"
My use case is providing a human-readable time stamp on a benchmark output so something really simple is what's best and the full tu stamp you give above exactly opposite to what I want; verbose and hard to read.
So
Date today mmddyyyy, ' ', Time now print24 '7/7/2016 09:22:40.914'
.914, ah, nanos. How useful. Let's get rid of them. No nanos: accessor so
Date today mmddyyyy, ' ', (Time now nanos: 0) print24 => MNU
but there's a seconds accessor, so
Date today mmddyyyy, ' ', (Time now seconds: Time now seconds; print24) '7/7/2016 00:00:41
?? So seconds: is private, and isn't the dual of Time seconds:
Time seconds ^ self second Time second ^ self asDuration seconds Duration seconds "Answer the number of seconds the receiver represents." ^seconds rem: SecondsInMinute
Looks broken to me.
Personally I think print24 should not print sub seconds.
cc'ing to Pharo because I want this timestamp to be the same in both dialects for a profiling tool we want to use in both dialects. _,,,^..^,,,_ best, Eliot
Hi Eliot, wanted the exact same thing, a short terse representation so I made one that employs "present context" -- e.g., if it is same day as today, just print the time, otherwise include both the Date and Time. This should be extended so if it is outside the current year, then it should include the year, otherwise not. Here's the old method, which could use a update, since #makeUTC is no longer necessary either.. printAbbreviatedOn: aStream | date | (date := self asDate) makeUTC = Date today ifTrue: [ self asTime print24: false showSeconds: false on: aStream ] ifFalse: [ aStream maPrint: ((date printFormat: #(2 1 3 $/ 1 2 1 )) copyUpToLast: $/) ; maPrint: $@. self asTime print24: false showSeconds: false on: aStream ] Another approach -- you could also play around with DateAndTime>>#printYMDOn:. On Thu, Jul 7, 2016 at 11:33 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
how does one produce a nice timestamp, simply date and time as in
7/7/2016 09:19:38
Trivial, right?
So
Date today mmddyyyy, ' ', Time now print24 '7/7/2016 09:22:40.914'
.914, ah, nanos. How useful. Let's get rid of them. No nanos: accessor so
Date today mmddyyyy, ' ', (Time now nanos: 0) print24 => MNU
but there's a seconds accessor, so
Date today mmddyyyy, ' ', (Time now seconds: Time now seconds; print24) '7/7/2016 00:00:41
?? So seconds: is private, and isn't the dual of Time seconds:
Time seconds ^ self second Time second ^ self asDuration seconds Duration seconds "Answer the number of seconds the receiver represents." ^seconds rem: SecondsInMinute
Looks broken to me.
Personally I think print24 should not print sub seconds.
cc'ing to Pharo because I want this timestamp to be the same in both dialects for a profiling tool we want to use in both dialects. _,,,^..^,,,_ best, Eliot
Le 07/07/2016 à 18:33, Eliot Miranda a écrit :
Hi All,
how does one produce a nice timestamp, simply date and time as in
7/7/2016 09:19:38
Trivial, right?
Hi Eliot, At synectique, for a simple solution, we added a class extension: `DateAndTime>>asSynectiqueFormat ^ '{1} {2}' format: {(self asDate mmddyyyy). (self asTime print24 first: 8)}` But it's true that a user will not need the milliseconds most of the time. It would be nice to have this kind of methods directly inside Pharo/Squeak.
So
Date today mmddyyyy, ' ', Time now print24 '7/7/2016 09:22:40.914'
.914, ah, nanos. How useful. Let's get rid of them. No nanos: accessor so
Date today mmddyyyy, ' ', (Time now nanos: 0) print24 => MNU
but there's a seconds accessor, so
Date today mmddyyyy, ' ', (Time now seconds: Time now seconds; print24) '7/7/2016 00:00:41
?? So seconds: is private, and isn't the dual of Time seconds:
Time seconds ^ self second Time second ^ self asDuration seconds Duration seconds "Answer the number of seconds the receiver represents." ^seconds rem: SecondsInMinute
Looks broken to me.
Personally I think print24 should not print sub seconds.
cc'ing to Pharo because I want this timestamp to be the same in both dialects for a profiling tool we want to use in both dialects. _,,,^..^,,,_ best, Eliot
-- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France
Hi All,
On Jul 7, 2016, at 9:33 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
how does one produce a nice timestamp, simply date and time as in
7/7/2016 09:19:38
Trivial, right?
So
Date today mmddyyyy, ' ', Time now print24 '7/7/2016 09:22:40.914'
.914, ah, nanos. How useful. Let's get rid of them. No nanos: accessor so
Date today mmddyyyy, ' ', (Time now nanos: 0) print24 => MNU
but there's a seconds accessor, so
Date today mmddyyyy, ' ', (Time now seconds: Time now seconds; print24) '7/7/2016 00:00:41
?? So seconds: is private, and isn't the dual of Time seconds:
Time seconds ^ self second Time second ^ self asDuration seconds Duration seconds "Answer the number of seconds the receiver represents." ^seconds rem: SecondsInMinute
Looks broken to me.
Let me be more explicit, and ask for permission to fix this. One basic bug is the asymmetry between seconds, an accessor that answers seconds mod 60, and seconds: that doesn't set seconds mod 60. But seconds: is private and could be replaced by eg setTotalSeconds:, presumably without breaking clients, allowing seconds: to be redefined to do the right thing. I note that the historic bug of changing the semantics of Time now to answer something with finer resolution than one second could have been avoided by adding eg exactlyNow or preciselyNow. The problem with nanos (apart from the horrible abbreviation) is that it presumes a maximum precision that isn't well chosen. Microseconds work out much better. And I hope we change the internal representation accordingly. But there needs to be done accessor that rounds to the nearest second without revealing the internal precision. Time now toTheNearestSecond or Time theNearestSecondNow or...?
Personally I think print24 should not print sub seconds.
cc'ing to Pharo because I want this timestamp to be the same in both dialects for a profiling tool we want to use in both dialects. _,,,^..^,,,_ best, Eliot
Eliot, I'm not against your suggestion about seconds:, but there is no way you should have to mutate an object for sake of only printing it. It should merely be the responsibility of the printing to meet the needed requirement. On Fri, Jul 8, 2016 at 12:49 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
On Jul 7, 2016, at 9:33 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
how does one produce a nice timestamp, simply date and time as in
7/7/2016 09:19:38
Trivial, right?
So
Date today mmddyyyy, ' ', Time now print24 '7/7/2016 09:22:40.914'
.914, ah, nanos. How useful. Let's get rid of them. No nanos: accessor so
Date today mmddyyyy, ' ', (Time now nanos: 0) print24 => MNU
but there's a seconds accessor, so
Date today mmddyyyy, ' ', (Time now seconds: Time now seconds; print24) '7/7/2016 00:00:41
?? So seconds: is private, and isn't the dual of Time seconds:
Time seconds ^ self second Time second ^ self asDuration seconds Duration seconds "Answer the number of seconds the receiver represents." ^seconds rem: SecondsInMinute
Looks broken to me.
Let me be more explicit, and ask for permission to fix this. One basic bug is the asymmetry between seconds, an accessor that answers seconds mod 60, and seconds: that doesn't set seconds mod 60. But seconds: is private and could be replaced by eg setTotalSeconds:, presumably without breaking clients, allowing seconds: to be redefined to do the right thing.
I note that the historic bug of changing the semantics of Time now to answer something with finer resolution than one second could have been avoided by adding eg exactlyNow or preciselyNow.
The problem with nanos (apart from the horrible abbreviation) is that it presumes a maximum precision that isn't well chosen. Microseconds work out much better. And I hope we change the internal representation accordingly. But there needs to be done accessor that rounds to the nearest second without revealing the internal precision. Time now toTheNearestSecond or Time theNearestSecondNow or...?
Personally I think print24 should not print sub seconds.
cc'ing to Pharo because I want this timestamp to be the same in both dialects for a profiling tool we want to use in both dialects. _,,,^..^,,,_ best, Eliot
On Fri, Jul 08, 2016 at 09:11:46PM -0500, Chris Muller wrote:
Eliot, I'm not against your suggestion about seconds:, but there is no way you should have to mutate an object for sake of only printing it. It should merely be the responsibility of the printing to meet the needed requirement.
+1 Dave
On Fri, Jul 8, 2016 at 12:49 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
On Jul 7, 2016, at 9:33 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
how does one produce a nice timestamp, simply date and time as in
7/7/2016 09:19:38
Trivial, right?
So
Date today mmddyyyy, ' ', Time now print24 '7/7/2016 09:22:40.914'
.914, ah, nanos. How useful. Let's get rid of them. No nanos: accessor so
Date today mmddyyyy, ' ', (Time now nanos: 0) print24 => MNU
but there's a seconds accessor, so
Date today mmddyyyy, ' ', (Time now seconds: Time now seconds; print24) '7/7/2016 00:00:41
?? So seconds: is private, and isn't the dual of Time seconds:
Time seconds ^ self second Time second ^ self asDuration seconds Duration seconds "Answer the number of seconds the receiver represents." ^seconds rem: SecondsInMinute
Looks broken to me.
Let me be more explicit, and ask for permission to fix this. One basic bug is the asymmetry between seconds, an accessor that answers seconds mod 60, and seconds: that doesn't set seconds mod 60. But seconds: is private and could be replaced by eg setTotalSeconds:, presumably without breaking clients, allowing seconds: to be redefined to do the right thing.
I note that the historic bug of changing the semantics of Time now to answer something with finer resolution than one second could have been avoided by adding eg exactlyNow or preciselyNow.
The problem with nanos (apart from the horrible abbreviation) is that it presumes a maximum precision that isn't well chosen. Microseconds work out much better. And I hope we change the internal representation accordingly. But there needs to be done accessor that rounds to the nearest second without revealing the internal precision. Time now toTheNearestSecond or Time theNearestSecondNow or...?
Personally I think print24 should not print sub seconds.
cc'ing to Pharo because I want this timestamp to be the same in both dialects for a profiling tool we want to use in both dialects. _,,,^..^,,,_ best, Eliot
But there needs to be done accessor that rounds to the nearest second without revealing the internal precision. Time now toTheNearestSecond or Time theNearestSecondNow or...?
Time now truncatedTo: 1 second. Time now roundedTo: 1 second.
On Thu, Jul 07, 2016 at 10:49:10PM -0700, Eliot Miranda wrote:
Hi All,
On Jul 7, 2016, at 9:33 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
how does one produce a nice timestamp, simply date and time as in
7/7/2016 09:19:38
Trivial, right?
So
Date today mmddyyyy, ' ', Time now print24 '7/7/2016 09:22:40.914'
.914, ah, nanos. How useful. Let's get rid of them. No nanos: accessor so
Date today mmddyyyy, ' ', (Time now nanos: 0) print24 => MNU
but there's a seconds accessor, so
Date today mmddyyyy, ' ', (Time now seconds: Time now seconds; print24) '7/7/2016 00:00:41
?? So seconds: is private, and isn't the dual of Time seconds:
Time seconds ^ self second Time second ^ self asDuration seconds Duration seconds "Answer the number of seconds the receiver represents." ^seconds rem: SecondsInMinute
Looks broken to me.
Let me be more explicit, and ask for permission to fix this. One basic bug is the asymmetry between seconds, an accessor that answers seconds mod 60, and seconds: that doesn't set seconds mod 60. But seconds: is private and could be replaced by eg setTotalSeconds:, presumably without breaking clients, allowing seconds: to be redefined to do the right thing.
Yes please fix it. It is clearly wrong to have #seconds and #seconds: refer to two different things. And since #seconds: is private, that would be the thing to change. Changing it to #setTotalSeconds: would be good, although I note that there is a #asSeconds method too, so maybe #setSeconds: might match better with #asSeconds. But either would be fine, and yes please, go ahead and fix it.
I note that the historic bug of changing the semantics of Time now to answer something with finer resolution than one second could have been avoided by adding eg exactlyNow or preciselyNow.
I'm not sure it is a bug, more like a difference in presentation versus internal representation. I think that #now should mean "now", not "now rounded to the nearest second". But if I display the time now, I probably would prefer it to be displayed to the nearest second.
The problem with nanos (apart from the horrible abbreviation) is that it presumes a maximum precision that isn't well chosen. Microseconds work out much better. And I hope we change the internal representation accordingly. But there needs to be done accessor that rounds to the nearest second without revealing the internal precision. Time now toTheNearestSecond or Time theNearestSecondNow or...?
Absolutely right. In the UTCDateAndTime changes, the magnitude of DateAndTime is utcMicroseconds for exactly this reason. That does not preclude nanosecond precision, it just means that the common case of microsecond precision uses an integer, and higher precisions are represented as Fraction. So the common case is fast, and higher precision remains possible. Somewhat more generally, the scale is in units of seconds. Precision should be unlimited (any Number) and accuracy is dependent on the underlying system clock (milliseconds or maybe microseconds if you are lucky). Most everyday computers may be accurate to milliseconds but report precision to microseconds. Specialized real time systems (e.g. GPS) may legitimately deal with higher accuracies and are probably not lying if they claim nanosecond precision. Human beings may drift a few hours one way or the other without noticing the difference, and are thus generally satisfied with full second precision and not much accuracy at all ;-) Dave
Personally I think print24 should not print sub seconds.
cc'ing to Pharo because I want this timestamp to be the same in both dialects for a profiling tool we want to use in both dialects. _,,,^..^,,,_ best, Eliot
On 07.07.2016, at 18:33, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
how does one produce a nice timestamp, simply date and time as in
7/7/2016 09:19:38
What's with 'TimeStamp now' (prints '8 July 2016 10:34:36 am') or this one: TimeStamp now in: [:t | String streamContents: [:s | t asDate printOn: s format: #(2 1 3 $/ 1 1 2). s space. t asTime print24: true showSeconds: true on: s]] Too bad TimeStamp is deprecated in Pharo4, so this works in pharo: DateAndTime now rounded in: [:t | String streamContents: [:s | t asDate printOn: s format: #(2 1 3 $/ 1 1 2). s space. t asTime print24: true showSeconds: true on: s]] But DateAndTime knows no #rounded in Squeak, buuut:
=======================
This works for both: DateAndTime now in: [:t | String streamContents: [:s | t asDate printOn: s format: #(2 1 3 $/ 1 1 2). s space. t printHMSOn: s]] ===== Best regards -Tobias PS: I'd prefer ISO, nonetheless: https://xkcd.com/1179/ (or the German way: 25.12.2015 :P)
Trivial, right?
So
Date today mmddyyyy, ' ', Time now print24 '7/7/2016 09:22:40.914'
.914, ah, nanos. How useful. Let's get rid of them. No nanos: accessor so
Date today mmddyyyy, ' ', (Time now nanos: 0) print24 => MNU
but there's a seconds accessor, so
Date today mmddyyyy, ' ', (Time now seconds: Time now seconds; print24) '7/7/2016 00:00:41
?? So seconds: is private, and isn't the dual of Time seconds:
Time seconds ^ self second Time second ^ self asDuration seconds Duration seconds "Answer the number of seconds the receiver represents." ^seconds rem: SecondsInMinute
Looks broken to me.
Personally I think print24 should not print sub seconds.
cc'ing to Pharo because I want this timestamp to be the same in both dialects for a profiling tool we want to use in both dialects. _,,,^..^,,,_ best, Eliot
On 08 Jul 2016, at 10:49, Tobias Pape <Das.Linux@gmx.de> wrote:
On 07.07.2016, at 18:33, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
how does one produce a nice timestamp, simply date and time as in
7/7/2016 09:19:38
What's with 'TimeStamp now' (prints '8 July 2016 10:34:36 am')
or this one:
TimeStamp now in: [:t | String streamContents: [:s | t asDate printOn: s format: #(2 1 3 $/ 1 1 2). s space. t asTime print24: true showSeconds: true on: s]]
Too bad TimeStamp is deprecated in Pharo4, so this works in pharo:
Yes, it is gone. It was a subclass whose only feature was a different print representation. It was also confusing, why choose it or DateAndTime. We folded TimeStamp's functionality into DateAndTime (see #printSeparateDateAndTimeOn: and #readSeparateDateAndTimeFrom:)
DateAndTime now rounded in: [:t | String streamContents: [:s | t asDate printOn: s format: #(2 1 3 $/ 1 1 2). s space. t asTime print24: true showSeconds: true on: s]]
But DateAndTime knows no #rounded in Squeak, buuut:
=======================
This works for both:
DateAndTime now in: [:t | String streamContents: [:s | t asDate printOn: s format: #(2 1 3 $/ 1 1 2). s space. t printHMSOn: s]]
=====
Best regards -Tobias
PS: I'd prefer ISO, nonetheless: https://xkcd.com/1179/
Yes, that was my point exactly. Thanks for the cool link! In the same line, the AM/PM don't make sense, and the timezone (or Z) is required. https://en.wikipedia.org/wiki/ISO_8601 Something like 2016-07-08 08:41:52 Z or 2016-07-08 08:41:52 +00:00 is perfectly readable. BTW, these are unambigiously parseable as well (for example, using ZTimestamp). ZTimestamp readFromString: '2016-07-08 08:41:52 Z'. "2016-07-08T08:41:52Z" ZTimestamp readFromString: '2016-07-08 08:41:52 +00:00'. "2016-07-08T08:41:52Z" Using ZTimestampFormat, which is an example based formatter/parser, like Go's, you can easily produce this slightly more human friendly format. (ZTimestampFormat fromString: '2001-02-03 16:05:06 +00:00') format: DateAndTime now. "'2016-07-08 11:16:54 +02:00'" And the reverse (obviously you share/predefine/cache the specific format object). (ZTimestampFormat fromString: '2001-02-03 16:05:06 +00:00') createDateAndTime; parse: '2016-07-08 11:16:54 +02:00'. "2016-07-08T11:16:54+02:00"
(or the German way: 25.12.2015 :P)
Trivial, right?
So
Date today mmddyyyy, ' ', Time now print24 '7/7/2016 09:22:40.914'
.914, ah, nanos. How useful. Let's get rid of them. No nanos: accessor so
Date today mmddyyyy, ' ', (Time now nanos: 0) print24 => MNU
but there's a seconds accessor, so
Date today mmddyyyy, ' ', (Time now seconds: Time now seconds; print24) '7/7/2016 00:00:41
?? So seconds: is private, and isn't the dual of Time seconds:
Time seconds ^ self second Time second ^ self asDuration seconds Duration seconds "Answer the number of seconds the receiver represents." ^seconds rem: SecondsInMinute
Looks broken to me.
Personally I think print24 should not print sub seconds.
cc'ing to Pharo because I want this timestamp to be the same in both dialects for a profiling tool we want to use in both dialects. _,,,^..^,,,_ best, Eliot
+ 1 Iso is really good. Because in France the format is the inverse than in english so months and days are really confusing. In addition Iso works really well for sorting files. Stef Le 8/7/16 à 11:23, Sven Van Caekenberghe a écrit :
On 08 Jul 2016, at 10:49, Tobias Pape <Das.Linux@gmx.de> wrote:
On 07.07.2016, at 18:33, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
how does one produce a nice timestamp, simply date and time as in
7/7/2016 09:19:38 What's with 'TimeStamp now' (prints '8 July 2016 10:34:36 am')
or this one:
TimeStamp now in: [:t | String streamContents: [:s | t asDate printOn: s format: #(2 1 3 $/ 1 1 2). s space. t asTime print24: true showSeconds: true on: s]]
Too bad TimeStamp is deprecated in Pharo4, so this works in pharo: Yes, it is gone. It was a subclass whose only feature was a different print representation. It was also confusing, why choose it or DateAndTime.
We folded TimeStamp's functionality into DateAndTime (see #printSeparateDateAndTimeOn: and #readSeparateDateAndTimeFrom:)
DateAndTime now rounded in: [:t | String streamContents: [:s | t asDate printOn: s format: #(2 1 3 $/ 1 1 2). s space. t asTime print24: true showSeconds: true on: s]]
But DateAndTime knows no #rounded in Squeak, buuut:
======================= This works for both:
DateAndTime now in: [:t | String streamContents: [:s | t asDate printOn: s format: #(2 1 3 $/ 1 1 2). s space. t printHMSOn: s]]
=====
Best regards -Tobias
PS: I'd prefer ISO, nonetheless: https://xkcd.com/1179/ Yes, that was my point exactly. Thanks for the cool link!
In the same line, the AM/PM don't make sense, and the timezone (or Z) is required.
https://en.wikipedia.org/wiki/ISO_8601
Something like 2016-07-08 08:41:52 Z or 2016-07-08 08:41:52 +00:00 is perfectly readable.
BTW, these are unambigiously parseable as well (for example, using ZTimestamp).
ZTimestamp readFromString: '2016-07-08 08:41:52 Z'.
"2016-07-08T08:41:52Z"
ZTimestamp readFromString: '2016-07-08 08:41:52 +00:00'.
"2016-07-08T08:41:52Z"
Using ZTimestampFormat, which is an example based formatter/parser, like Go's, you can easily produce this slightly more human friendly format.
(ZTimestampFormat fromString: '2001-02-03 16:05:06 +00:00') format: DateAndTime now.
"'2016-07-08 11:16:54 +02:00'"
And the reverse (obviously you share/predefine/cache the specific format object).
(ZTimestampFormat fromString: '2001-02-03 16:05:06 +00:00') createDateAndTime; parse: '2016-07-08 11:16:54 +02:00'.
"2016-07-08T11:16:54+02:00"
(or the German way: 25.12.2015 :P)
Trivial, right?
So
Date today mmddyyyy, ' ', Time now print24 '7/7/2016 09:22:40.914'
.914, ah, nanos. How useful. Let's get rid of them. No nanos: accessor so
Date today mmddyyyy, ' ', (Time now nanos: 0) print24 => MNU
but there's a seconds accessor, so
Date today mmddyyyy, ' ', (Time now seconds: Time now seconds; print24) '7/7/2016 00:00:41
?? So seconds: is private, and isn't the dual of Time seconds:
Time seconds ^ self second Time second ^ self asDuration seconds Duration seconds "Answer the number of seconds the receiver represents." ^seconds rem: SecondsInMinute
Looks broken to me.
Personally I think print24 should not print sub seconds.
cc'ing to Pharo because I want this timestamp to be the same in both dialects for a profiling tool we want to use in both dialects. _,,,^..^,,,_ best, Eliot
I like the idea of Go to have a separate date-printer. Stef Le 8/7/16 à 11:23, Sven Van Caekenberghe a écrit :
On 08 Jul 2016, at 10:49, Tobias Pape <Das.Linux@gmx.de> wrote:
On 07.07.2016, at 18:33, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
how does one produce a nice timestamp, simply date and time as in
7/7/2016 09:19:38 What's with 'TimeStamp now' (prints '8 July 2016 10:34:36 am')
or this one:
TimeStamp now in: [:t | String streamContents: [:s | t asDate printOn: s format: #(2 1 3 $/ 1 1 2). s space. t asTime print24: true showSeconds: true on: s]]
Too bad TimeStamp is deprecated in Pharo4, so this works in pharo: Yes, it is gone. It was a subclass whose only feature was a different print representation. It was also confusing, why choose it or DateAndTime.
We folded TimeStamp's functionality into DateAndTime (see #printSeparateDateAndTimeOn: and #readSeparateDateAndTimeFrom:)
DateAndTime now rounded in: [:t | String streamContents: [:s | t asDate printOn: s format: #(2 1 3 $/ 1 1 2). s space. t asTime print24: true showSeconds: true on: s]]
But DateAndTime knows no #rounded in Squeak, buuut:
======================= This works for both:
DateAndTime now in: [:t | String streamContents: [:s | t asDate printOn: s format: #(2 1 3 $/ 1 1 2). s space. t printHMSOn: s]]
=====
Best regards -Tobias
PS: I'd prefer ISO, nonetheless: https://xkcd.com/1179/ Yes, that was my point exactly. Thanks for the cool link!
In the same line, the AM/PM don't make sense, and the timezone (or Z) is required.
https://en.wikipedia.org/wiki/ISO_8601
Something like 2016-07-08 08:41:52 Z or 2016-07-08 08:41:52 +00:00 is perfectly readable.
BTW, these are unambigiously parseable as well (for example, using ZTimestamp).
ZTimestamp readFromString: '2016-07-08 08:41:52 Z'.
"2016-07-08T08:41:52Z"
ZTimestamp readFromString: '2016-07-08 08:41:52 +00:00'.
"2016-07-08T08:41:52Z"
Using ZTimestampFormat, which is an example based formatter/parser, like Go's, you can easily produce this slightly more human friendly format.
(ZTimestampFormat fromString: '2001-02-03 16:05:06 +00:00') format: DateAndTime now.
"'2016-07-08 11:16:54 +02:00'"
And the reverse (obviously you share/predefine/cache the specific format object).
(ZTimestampFormat fromString: '2001-02-03 16:05:06 +00:00') createDateAndTime; parse: '2016-07-08 11:16:54 +02:00'.
"2016-07-08T11:16:54+02:00"
(or the German way: 25.12.2015 :P)
Trivial, right?
So
Date today mmddyyyy, ' ', Time now print24 '7/7/2016 09:22:40.914'
.914, ah, nanos. How useful. Let's get rid of them. No nanos: accessor so
Date today mmddyyyy, ' ', (Time now nanos: 0) print24 => MNU
but there's a seconds accessor, so
Date today mmddyyyy, ' ', (Time now seconds: Time now seconds; print24) '7/7/2016 00:00:41
?? So seconds: is private, and isn't the dual of Time seconds:
Time seconds ^ self second Time second ^ self asDuration seconds Duration seconds "Answer the number of seconds the receiver represents." ^seconds rem: SecondsInMinute
Looks broken to me.
Personally I think print24 should not print sub seconds.
cc'ing to Pharo because I want this timestamp to be the same in both dialects for a profiling tool we want to use in both dialects. _,,,^..^,,,_ best, Eliot
On Fri, Jul 08, 2016 at 10:49:51AM +0200, Tobias Pape wrote:
On 07.07.2016, at 18:33, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
how does one produce a nice timestamp, simply date and time as in
7/7/2016 09:19:38
...
PS: I'd prefer ISO, nonetheless: https://xkcd.com/1179/
+2 (1 for ISO and 1 for the xkcd reference) Cheers, Alistair
+100 for ISO. ----- Brad Selfridge -- View this message in context: http://forum.world.st/Time-now-print24-tp4905425p4905677.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (9)
-
Alistair Grant -
Brad Selfridge -
Chris Muller -
Cyril Ferlicot D. -
David T. Lewis -
Eliot Miranda -
stepharo -
Sven Van Caekenberghe -
Tobias Pape