<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div><br>On Nov 20, 2016, at 8:14 PM, Chris Muller <<a href="mailto:ma.chris.m@gmail.com">ma.chris.m@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I may have misunderstood; I thought it was defined in terms of a particular timezone and that the proposal was simply to shift it in order to line up with UTC. I thought it was simply a naming / conversion issue balanced against legacy compatibility; I didn't think about the more serious ambiguity issue you pointed out.</div><div><br></div><div>So then there may be no way to avoid changing the legacy method, but that question always deserves to be asked; "is there a compatible way to address it?"<br></div></div></div></div></div></blockquote><div><br></div>keep fromSeconds: interpreting its argument as local seconds and add fromUTCSeconds: which <span style="background-color: rgba(255, 255, 255, 0);">interprets its argument as local second.</span><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Best,</div><div> Chris</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't agree that the Squeak epoch was "supposed" to have been<br>
defined relative to UTC. Its just a number, it don't see that it<br>
</blockquote>
<br>
Do you mean that it shouldn't have any time zone defined?<br>
If yes, then it is so ambiguous that we should look for another epoch. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
(The current ambiguity makes me implement new time classes whenever it's relevant.)<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
matters when or what number we start with, as long as it satisfies its<br>
requirement of being a numerical representation, and we don't change<br>
it. Changing it would be breaking it for all applications which ever<br>
used it.<br>
</blockquote>
<br>
So, when these time stamps are created on different machines in different time zones at the same time, then it's perfectly okay to have different numbers?<br>
<br>
Levente<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Sat, Nov 19, 2016 at 10:12 PM, David T. Lewis <<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Nov 18, 2016 at 07:01:29PM +0100, Bert Freudenberg wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Fri, Nov 18, 2016 at 2:16 PM, Edgar De Cleene <<a href="mailto:edgardec2005@gmail.com" target="_blank">edgardec2005@gmail.com</a>><br>
wrote:<br>
<br>
> Fellows:<br>
> I found useful add UnixTime at the beginning of file names for you have<br>
> nnnFoo.etc what is compatible with different OS and you easily see ordered<br>
> .<br>
><br>
> But I my image I do not have how convert this value to DateAndTime again.<br>
> So i attach this just in case some could use it.<br>
><br>
<br>
Since we already have DateAndTime>>asUnixTime, having DateAndTime<br>
class>>fromUnixTime: seems like a reasonable addition. Thank you!<br>
<br>
- Bert -<br>
</blockquote>
<br>
Edgar's enhancement looks good to me also, but unfortunately it does not<br>
work due to a problem in DateAndTime class>>fromSeconds:, which is supposed<br>
to do this:<br>
<br>
DateAndTime class>>fromSeconds: seconds<br>
"Answer a DateAndTime since the Squeak epoch: 1 January 1901"<br>
<br>
<br>
If we agree that the Squeak epoch was supposed to have been defined relative<br>
to UTC, then #fromSeconds: is broken because it treats its argument as<br>
seconds since the "local Squeak epoch" (early Squeak VMs were built upon<br>
the faulty premise of using local time).<br>
<br>
Because of this problem in #fromSeconds: we get the following (I am five<br>
hours from GMT):<br>
<br>
dt1 := DateAndTime now.<br>
unixSeconds1 := dt1 asUnixTime.<br>
dt2 := DateAndTime fromUnixTime: unixSeconds1.<br>
unixSeconds2 := dt2 asUnixTime.<br>
dt2 - dt1. ==> 0:04:59:59.890588<br>
unixSeconds2 - unixSeconds1. ==> 18000<br>
<br>
IMO, Edgar's method is correct and we should fix DateAndTime class>>fromSeconds:<br>
so that the argument is interpreted as seconds since the UTC Smalltalk epoch.<br>
<br>
<OT><br>
Note also that #asUnixTime truncates (or rounds?) to a whole second, which is<br>
reasonable given that Unix time(2) does the same thing. But it might deserve<br>
a method comment if that is the intended behavior. If the method was named<br>
#asPosixTime, then I might argue that the value should not be rounded or<br>
truncated.<br>
</OT><br>
<br>
Dave<br>
<br>
<br>
</blockquote></blockquote>
</blockquote></div><br></div></div>
</div></blockquote><blockquote type="cite"><div><span></span><br></div></blockquote></div></body></html>