UnixTime
Locked
 
|
Fellows:
I found useful add UnixTime at the beginning of file names for you have nnnFoo.etc what is compatible with different OS and you easily see ordered . But I my image I do not have how convert this value to DateAndTime again. So i attach this just in case some could use it. |
DateAndTime class-fromUnixTime.st (362 bytes) |
|
Since we already have DateAndTime>>asUnixTime, having DateAndTime class>>fromUnixTime: seems like a reasonable addition. Thank you! - Bert - On Fri, Nov 18, 2016 at 2:16 PM, Edgar De Cleene <[hidden email]> wrote: Fellows: |
|
|
On Fri, Nov 18, 2016 at 07:01:29PM +0100, Bert Freudenberg wrote:
> > On Fri, Nov 18, 2016 at 2:16 PM, Edgar De Cleene <[hidden email]> > wrote: > > > Fellows: > > I found useful add UnixTime at the beginning of file names for you have > > nnnFoo.etc what is compatible with different OS and you easily see ordered > > . > > > > But I my image I do not have how convert this value to DateAndTime again. > > So i attach this just in case some could use it. > > > > Since we already have DateAndTime>>asUnixTime, having DateAndTime > class>>fromUnixTime: seems like a reasonable addition. Thank you! > > - Bert - Edgar's enhancement looks good to me also, but unfortunately it does not work due to a problem in DateAndTime class>>fromSeconds:, which is supposed to do this: DateAndTime class>>fromSeconds: seconds "Answer a DateAndTime since the Squeak epoch: 1 January 1901" If we agree that the Squeak epoch was supposed to have been defined relative to UTC, then #fromSeconds: is broken because it treats its argument as seconds since the "local Squeak epoch" (early Squeak VMs were built upon the faulty premise of using local time). Because of this problem in #fromSeconds: we get the following (I am five hours from GMT): dt1 := DateAndTime now. unixSeconds1 := dt1 asUnixTime. dt2 := DateAndTime fromUnixTime: unixSeconds1. unixSeconds2 := dt2 asUnixTime. dt2 - dt1. ==> 0:04:59:59.890588 unixSeconds2 - unixSeconds1. ==> 18000 IMO, Edgar's method is correct and we should fix DateAndTime class>>fromSeconds: so that the argument is interpreted as seconds since the UTC Smalltalk epoch. <OT> Note also that #asUnixTime truncates (or rounds?) to a whole second, which is reasonable given that Unix time(2) does the same thing. But it might deserve a method comment if that is the intended behavior. If the method was named #asPosixTime, then I might argue that the value should not be rounded or truncated. </OT> Dave |
|
|
I use a forked Squeak 4.5 If i do DateAndTime today 2016-11-20T00:00:00+01:00 DateAndTime today asUnixTime 1479596400 DateAndTime fromUnixTime: 1479596400 2016-11-19T23:00:00+01:00 The intended use is for put it in FileName compatible to all OS 1479596400NameOfFile.extension An example Parsing the links and convert the html to objects Then saving this objects gives 1477612800Environment initialize.obj 1477612800Environment withName aName.obj 1477612800Environment.obj 1478131200JSON.obj 1478131200SIXX.obj 1478131200STON.obj 1478476800Monticello Basics.obj 1478563200Seaside status November 2016.obj 1478563200Seaside.obj If you do( DateAndTime fromUnixTime:1478563200) asDate gives 8 November 2016 I understand you point but the current implementation is enough to me.Edgar
|
|
|
In reply to this post by David T. Lewis
We use [DateAndTime unixEpoch + 1479647248 seconds] whenever we need such
conversion. It's quicker and it also avoids the time zone issue of #fromSeconds:. Levente On Sat, 19 Nov 2016, David T. Lewis wrote: > On Fri, Nov 18, 2016 at 07:01:29PM +0100, Bert Freudenberg wrote: >> >> On Fri, Nov 18, 2016 at 2:16 PM, Edgar De Cleene <[hidden email]> >> wrote: >> >> > Fellows: >> > I found useful add UnixTime at the beginning of file names for you have >> > nnnFoo.etc what is compatible with different OS and you easily see ordered >> > . >> > >> > But I my image I do not have how convert this value to DateAndTime again. >> > So i attach this just in case some could use it. >> > >> >> Since we already have DateAndTime>>asUnixTime, having DateAndTime >> class>>fromUnixTime: seems like a reasonable addition. Thank you! >> >> - Bert - > > Edgar's enhancement looks good to me also, but unfortunately it does not > work due to a problem in DateAndTime class>>fromSeconds:, which is supposed > to do this: > > DateAndTime class>>fromSeconds: seconds > "Answer a DateAndTime since the Squeak epoch: 1 January 1901" > > > If we agree that the Squeak epoch was supposed to have been defined relative > to UTC, then #fromSeconds: is broken because it treats its argument as > seconds since the "local Squeak epoch" (early Squeak VMs were built upon > the faulty premise of using local time). > > Because of this problem in #fromSeconds: we get the following (I am five > hours from GMT): > > dt1 := DateAndTime now. > unixSeconds1 := dt1 asUnixTime. > dt2 := DateAndTime fromUnixTime: unixSeconds1. > unixSeconds2 := dt2 asUnixTime. > dt2 - dt1. ==> 0:04:59:59.890588 > unixSeconds2 - unixSeconds1. ==> 18000 > > IMO, Edgar's method is correct and we should fix DateAndTime class>>fromSeconds: > so that the argument is interpreted as seconds since the UTC Smalltalk epoch. > > <OT> > Note also that #asUnixTime truncates (or rounds?) to a whole second, which is > reasonable given that Unix time(2) does the same thing. But it might deserve > a method comment if that is the intended behavior. If the method was named > #asPosixTime, then I might argue that the value should not be rounded or > truncated. > </OT> > > Dave |
|
|
In reply to this post by David T. Lewis
I don't agree that the Squeak epoch was "supposed" to have been
defined relative to UTC. Its just a number, it don't see that it matters when or what number we start with, as long as it satisfies its requirement of being a numerical representation, and we don't change it. Changing it would be breaking it for all applications which ever used it. On Sat, Nov 19, 2016 at 10:12 PM, David T. Lewis <[hidden email]> wrote: > On Fri, Nov 18, 2016 at 07:01:29PM +0100, Bert Freudenberg wrote: >> >> On Fri, Nov 18, 2016 at 2:16 PM, Edgar De Cleene <[hidden email]> >> wrote: >> >> > Fellows: >> > I found useful add UnixTime at the beginning of file names for you have >> > nnnFoo.etc what is compatible with different OS and you easily see ordered >> > . >> > >> > But I my image I do not have how convert this value to DateAndTime again. >> > So i attach this just in case some could use it. >> > >> >> Since we already have DateAndTime>>asUnixTime, having DateAndTime >> class>>fromUnixTime: seems like a reasonable addition. Thank you! >> >> - Bert - > > Edgar's enhancement looks good to me also, but unfortunately it does not > work due to a problem in DateAndTime class>>fromSeconds:, which is supposed > to do this: > > DateAndTime class>>fromSeconds: seconds > "Answer a DateAndTime since the Squeak epoch: 1 January 1901" > > > If we agree that the Squeak epoch was supposed to have been defined relative > to UTC, then #fromSeconds: is broken because it treats its argument as > seconds since the "local Squeak epoch" (early Squeak VMs were built upon > the faulty premise of using local time). > > Because of this problem in #fromSeconds: we get the following (I am five > hours from GMT): > > dt1 := DateAndTime now. > unixSeconds1 := dt1 asUnixTime. > dt2 := DateAndTime fromUnixTime: unixSeconds1. > unixSeconds2 := dt2 asUnixTime. > dt2 - dt1. ==> 0:04:59:59.890588 > unixSeconds2 - unixSeconds1. ==> 18000 > > IMO, Edgar's method is correct and we should fix DateAndTime class>>fromSeconds: > so that the argument is interpreted as seconds since the UTC Smalltalk epoch. > > <OT> > Note also that #asUnixTime truncates (or rounds?) to a whole second, which is > reasonable given that Unix time(2) does the same thing. But it might deserve > a method comment if that is the intended behavior. If the method was named > #asPosixTime, then I might argue that the value should not be rounded or > truncated. > </OT> > > Dave > > |
|
|
> On Nov 20, 2016, at 12:45 PM, Chris Muller <[hidden email]> wrote: > > I don't agree that the Squeak epoch was "supposed" to have been > defined relative to UTC. Its just a number, it don't see that it > matters when or what number we start with, as long as it satisfies its > requirement of being a numerical representation, and we don't change > it. Changing it would be breaking it for all applications which ever > used it. +1. And also requiring vm mods and breaking vm backward compatibility. IIABDFI. _,,,^..^,,,_ (phone) > >> On Sat, Nov 19, 2016 at 10:12 PM, David T. Lewis <[hidden email]> wrote: >>> On Fri, Nov 18, 2016 at 07:01:29PM +0100, Bert Freudenberg wrote: >>> >>> On Fri, Nov 18, 2016 at 2:16 PM, Edgar De Cleene <[hidden email]> >>> wrote: >>> >>>> Fellows: >>>> I found useful add UnixTime at the beginning of file names for you have >>>> nnnFoo.etc what is compatible with different OS and you easily see ordered >>>> . >>>> >>>> But I my image I do not have how convert this value to DateAndTime again. >>>> So i attach this just in case some could use it. >>>> >>> >>> Since we already have DateAndTime>>asUnixTime, having DateAndTime >>> class>>fromUnixTime: seems like a reasonable addition. Thank you! >>> >>> - Bert - >> >> Edgar's enhancement looks good to me also, but unfortunately it does not >> work due to a problem in DateAndTime class>>fromSeconds:, which is supposed >> to do this: >> >> DateAndTime class>>fromSeconds: seconds >> "Answer a DateAndTime since the Squeak epoch: 1 January 1901" >> >> >> If we agree that the Squeak epoch was supposed to have been defined relative >> to UTC, then #fromSeconds: is broken because it treats its argument as >> seconds since the "local Squeak epoch" (early Squeak VMs were built upon >> the faulty premise of using local time). >> >> Because of this problem in #fromSeconds: we get the following (I am five >> hours from GMT): >> >> dt1 := DateAndTime now. >> unixSeconds1 := dt1 asUnixTime. >> dt2 := DateAndTime fromUnixTime: unixSeconds1. >> unixSeconds2 := dt2 asUnixTime. >> dt2 - dt1. ==> 0:04:59:59.890588 >> unixSeconds2 - unixSeconds1. ==> 18000 >> >> IMO, Edgar's method is correct and we should fix DateAndTime class>>fromSeconds: >> so that the argument is interpreted as seconds since the UTC Smalltalk epoch. >> >> <OT> >> Note also that #asUnixTime truncates (or rounds?) to a whole second, which is >> reasonable given that Unix time(2) does the same thing. But it might deserve >> a method comment if that is the intended behavior. If the method was named >> #asPosixTime, then I might argue that the value should not be rounded or >> truncated. >> </OT> >> >> Dave >> >> > |
|
|
On Sun, Nov 20, 2016 at 01:04:07PM -0800, Eliot Miranda wrote:
> > > > On Nov 20, 2016, at 12:45 PM, Chris Muller <[hidden email]> wrote: > > > > I don't agree that the Squeak epoch was "supposed" to have been > > defined relative to UTC. Its just a number, it don't see that it > > matters when or what number we start with, as long as it satisfies its > > requirement of being a numerical representation, and we don't change > > it. Changing it would be breaking it for all applications which ever > > used it. > > +1. And also requiring vm mods and breaking vm backward compatibility. IIABDFI. Um, no. Eliot, I think that you have previously explained that the Smalltalk epoch was intended to refer to 1 January 1901 GMT. That is a good thing because it makes sense, and also because the earlier implementations of Squeak and the VM were based on local time, which makes no sense at all. I was not suggesting any change with regard to this definition, and I was not suggesting any changes to the VM. What I am saying is that DateAndTime class>>fromSeconds: is broken because it's method comment says "Answer a DateAndTime since the Squeak epoch", and its implementation does not do that. Dave > > _,,,^..^,,,_ (phone) > > > >> On Sat, Nov 19, 2016 at 10:12 PM, David T. Lewis <[hidden email]> wrote: > >>> On Fri, Nov 18, 2016 at 07:01:29PM +0100, Bert Freudenberg wrote: > >>> > >>> On Fri, Nov 18, 2016 at 2:16 PM, Edgar De Cleene <[hidden email]> > >>> wrote: > >>> > >>>> Fellows: > >>>> I found useful add UnixTime at the beginning of file names for you have > >>>> nnnFoo.etc what is compatible with different OS and you easily see ordered > >>>> . > >>>> > >>>> But I my image I do not have how convert this value to DateAndTime again. > >>>> So i attach this just in case some could use it. > >>>> > >>> > >>> Since we already have DateAndTime>>asUnixTime, having DateAndTime > >>> class>>fromUnixTime: seems like a reasonable addition. Thank you! > >>> > >>> - Bert - > >> > >> Edgar's enhancement looks good to me also, but unfortunately it does not > >> work due to a problem in DateAndTime class>>fromSeconds:, which is supposed > >> to do this: > >> > >> DateAndTime class>>fromSeconds: seconds > >> "Answer a DateAndTime since the Squeak epoch: 1 January 1901" > >> > >> > >> If we agree that the Squeak epoch was supposed to have been defined relative > >> to UTC, then #fromSeconds: is broken because it treats its argument as > >> seconds since the "local Squeak epoch" (early Squeak VMs were built upon > >> the faulty premise of using local time). > >> > >> Because of this problem in #fromSeconds: we get the following (I am five > >> hours from GMT): > >> > >> dt1 := DateAndTime now. > >> unixSeconds1 := dt1 asUnixTime. > >> dt2 := DateAndTime fromUnixTime: unixSeconds1. > >> unixSeconds2 := dt2 asUnixTime. > >> dt2 - dt1. ==> 0:04:59:59.890588 > >> unixSeconds2 - unixSeconds1. ==> 18000 > >> > >> IMO, Edgar's method is correct and we should fix DateAndTime class>>fromSeconds: > >> so that the argument is interpreted as seconds since the UTC Smalltalk epoch. > >> > >> <OT> > >> Note also that #asUnixTime truncates (or rounds?) to a whole second, which is > >> reasonable given that Unix time(2) does the same thing. But it might deserve > >> a method comment if that is the intended behavior. If the method was named > >> #asPosixTime, then I might argue that the value should not be rounded or > >> truncated. > >> </OT> > >> > >> Dave > >> > >> > > > |
|
|
In reply to this post by Chris Muller-3
On Sun, 20 Nov 2016, Chris Muller wrote:
> I don't agree that the Squeak epoch was "supposed" to have been > defined relative to UTC. Its just a number, it don't see that it Do you mean that it shouldn't have any time zone defined? If yes, then it is so ambiguous that we should look for another epoch. (The current ambiguity makes me implement new time classes whenever it's relevant.) > matters when or what number we start with, as long as it satisfies its > requirement of being a numerical representation, and we don't change > it. Changing it would be breaking it for all applications which ever > used it. 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? Levente > > On Sat, Nov 19, 2016 at 10:12 PM, David T. Lewis <[hidden email]> wrote: >> On Fri, Nov 18, 2016 at 07:01:29PM +0100, Bert Freudenberg wrote: >>> >>> On Fri, Nov 18, 2016 at 2:16 PM, Edgar De Cleene <[hidden email]> >>> wrote: >>> >>> > Fellows: >>> > I found useful add UnixTime at the beginning of file names for you have >>> > nnnFoo.etc what is compatible with different OS and you easily see ordered >>> > . >>> > >>> > But I my image I do not have how convert this value to DateAndTime again. >>> > So i attach this just in case some could use it. >>> > >>> >>> Since we already have DateAndTime>>asUnixTime, having DateAndTime >>> class>>fromUnixTime: seems like a reasonable addition. Thank you! >>> >>> - Bert - >> >> Edgar's enhancement looks good to me also, but unfortunately it does not >> work due to a problem in DateAndTime class>>fromSeconds:, which is supposed >> to do this: >> >> DateAndTime class>>fromSeconds: seconds >> "Answer a DateAndTime since the Squeak epoch: 1 January 1901" >> >> >> If we agree that the Squeak epoch was supposed to have been defined relative >> to UTC, then #fromSeconds: is broken because it treats its argument as >> seconds since the "local Squeak epoch" (early Squeak VMs were built upon >> the faulty premise of using local time). >> >> Because of this problem in #fromSeconds: we get the following (I am five >> hours from GMT): >> >> dt1 := DateAndTime now. >> unixSeconds1 := dt1 asUnixTime. >> dt2 := DateAndTime fromUnixTime: unixSeconds1. >> unixSeconds2 := dt2 asUnixTime. >> dt2 - dt1. ==> 0:04:59:59.890588 >> unixSeconds2 - unixSeconds1. ==> 18000 >> >> IMO, Edgar's method is correct and we should fix DateAndTime class>>fromSeconds: >> so that the argument is interpreted as seconds since the UTC Smalltalk epoch. >> >> <OT> >> Note also that #asUnixTime truncates (or rounds?) to a whole second, which is >> reasonable given that Unix time(2) does the same thing. But it might deserve >> a method comment if that is the intended behavior. If the method was named >> #asPosixTime, then I might argue that the value should not be rounded or >> truncated. >> </OT> >> >> Dave >> >> |
|
|
On Mon, Nov 21, 2016 at 01:11:46AM +0100, Levente Uzonyi wrote:
> On Sun, 20 Nov 2016, Chris Muller wrote: > > >I don't agree that the Squeak epoch was "supposed" to have been > >defined relative to UTC. Its just a number, it don't see that it > > Do you mean that it shouldn't have any time zone defined? > If yes, then it is so ambiguous that we should look for another epoch. > > (The current ambiguity makes me implement new time classes whenever it's > relevant.) Which reminds me ... I would still welcome feedback on www.squeaksource.com/UTCDateAndTime, which can be loaded into a 64-bit trunk Spur image like this: (Installer ss project: 'UTCDateAndTime') install: 'Chronology-Core-dtl.3.mcz'. "load starting mcz" (MCMcmUpdater updateMapNamed: 'update' repository: 'http://www.squeaksource.com/UTCDateAndTime') doUpdate: false. Dave |
|
|
In reply to this post by Levente Uzonyi
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. 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?" Best, Chris I don't agree that the Squeak epoch was "supposed" to have been
|
|
|
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |