Epoch returns local offset
Locked
 
Administrator
|
In New York (EST), "DateAndTime epoch" -> "1901-01-01T00:00:00-04:00" (Squeak epoch offset by local timezone). Can that be right? It must be constant, no?
Thanks, Sean
Cheers,
Sean |
Re: Epoch returns local offset
|
Administrator
|
btw:
dos epoch: 1 January 1980 00:00+00:00 unix epoch: 1 January 1970 00:00+00:00
Cheers,
Sean |
Re: Epoch returns local offset
|
|
In reply to this post by Sean P. DeNigris
>>>>> "Sean" == Sean P DeNigris <[hidden email]> writes:
Sean> In New York (EST), "DateAndTime epoch" -> "1901-01-01T00:00:00-04:00" (Squeak Sean> epoch offset by local timezone). Can that be right? It must be constant, no? But it's not even EST right now (it's EDT), so this has nothing to do with the current time offset, in case that helps. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion |
Re: Epoch returns local offset
|
Administrator
|
You suck :-P j/k. Thanks Randal. So I guess there's two problems... 1. Pharo doesn't update for daylight savings time 2. epoch shouldn't offset by local offset?
Cheers,
Sean |
Re: Epoch returns local offset
|
|
In reply to this post by Randal L. Schwartz
On Wed, May 16, 2012 at 01:24:20PM -0700, Randal L. Schwartz wrote:
> >>>>> "Sean" == Sean P DeNigris <[hidden email]> writes: > > Sean> In New York (EST), "DateAndTime epoch" -> "1901-01-01T00:00:00-04:00" (Squeak > Sean> epoch offset by local timezone). Can that be right? It must be constant, no? > > But it's not even EST right now (it's EDT), so this has nothing to do > with the current time offset, in case that helps. :) > "DateAndTime epoch" refers to the Smalltalk epoch, which is an undefined entity. As long as the value contains 1901-01-01T00:00:00 it is not proveably wrong, because the "definition" of the Smalltalk epoch does not specify if it is intended to refer to a point in time measured in Palo Alto, California, Greenwich England, or New York City. So no, it is not a constant. Dave |
Re: Epoch returns local offset
|
Administrator
|
Let me rephrase: wouldn't it be better if it was a constant, like dos and unix? I find the current behavior confusing e.g. dt := '1/15/2012 0000+00:00' asDateAndTime. DateAndTime localTimeZone: (TimeZone timeZones detect: [ :e | e abbreviation = 'PDT' ]). s := dt asSeconds. "3504013200" "Now I move to Greenwich" DateAndTime localTimeZone: (TimeZone timeZones detect: [ :e | e abbreviation = 'UTC' ]). DateAndTime fromSeconds: s. "2012-01-14T17:00:00+00:00" "Oops!"
Cheers,
Sean |
Re: Epoch returns local offset
|
|
(cross posting to squeak-dev)
On Wed, May 16, 2012 at 01:50:16PM -0700, Sean P. DeNigris wrote: > > David T. Lewis wrote > > > > So no, it is not a constant. > > > > Let me rephrase: wouldn't it be better if it was a constant, like dos and > unix? Yes it would be better if the Smalltalk epoch was an unambiguously defined value, but unfortunately it is not. That is the reason that the clearly defined Posix epoch would be a more suitable basis for these calculations. <ot> Funny that you should mention DOS. DOS has exactly the same problem as Squeak/Pharo in this regard. It was originally designed as a simple single-user system, where the user was expected to set the clock properly on all of his/her alarm clocks, kitchen appliances, and computers. It has no knowledge of time zones or daylight savings time, and this leads to all sorts of bugs in applications running on MS-DOS that assume that the system time is correct. I was dealing with a real-life bug of this sort last week that had people spending huge amounts of time and energy trying to figure out what was causing clocks to be "reset" in a complex multi-platform application that happened to include some old DOS based computers that were sending time stamped messages. </ot> > I find the current behavior confusing e.g. > > dt := '1/15/2012 0000+00:00' asDateAndTime. > > DateAndTime localTimeZone: (TimeZone timeZones detect: [ :e | e abbreviation > = 'PDT' ]). > s := dt asSeconds. "3504013200" > > "Now I move to Greenwich" > DateAndTime localTimeZone: (TimeZone timeZones detect: [ :e | e abbreviation > = 'UTC' ]). > DateAndTime fromSeconds: s. "2012-01-14T17:00:00+00:00" "Oops!" > Yes, that looks broken to me too. But DateAndTime class>>fromSeconds: is documented as "Answer a DateAndTime since the Squeak epoch: 1 January 1901" which by definition cannot be correctly implemented. One solution would be to gain agreement among all flavors of Smalltalk as to the proper definition of the Smalltalk epoch. But it seems to me that it would be vastly simpler to just use a definition that is already agreed and documented (i.e. Posix epoch), and leave the "Smalltalk epoch" behind as an interesting historical artifact. Dave |
Re: Epoch returns local offset
|
Administrator
|
I created an issue... Issue 5913: Remove Squeak epoch http://code.google.com/p/pharo/issues/detail?id=5913
Cheers,
Sean |
|
|
Am 17.05.2012 um 05:48 schrieb "Sean P. DeNigris" <[hidden email]>: > > David T. Lewis wrote >> >> But it seems to me >> that it would be vastly simpler to just use a definition that is already >> agreed and documented (i.e. Posix epoch), and leave the "Smalltalk epoch" >> behind as an interesting historical artifact. >> > > I created an issue... > Issue 5913: Remove Squeak epoch > http://code.google.com/p/pharo/issues/detail?id=5913 > I've this on my todo sheet for a long time now. I started multiple times fixing things but never finished because there is loads to do. So let's join efforts. @David That is a good proposal to base calculation on posix epoch. I blindly assumed smalltalk epoch is wrong. So I better read the specs before changing DateAndTime>>#midnight Norbert > -- > View this message in context: http://forum.world.st/Epoch-returns-local-offset-tp4630549p4630604.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > |
Re: Epoch returns local offset
|
Administrator
|
Fix in inbox: Name: SLICE-Issue-5913-Remove-Squeak-epoch-SeanDeNigris.1
This was a complicated change that's obviously at the core of the system. Although all 385 of KernelTests-Chronology tests pass[1], I'd really appreciate some feedback and testing... [1] except the DateAndTime*EpochTest classes, which should be removed; see below General * Update all comments referencing the Squeak Epoch * There is a VM primitive that returns current seconds since the Squeak epoch. For now, I have adjusted all users of this primitive for the Unix epoch, but it would be cleaner to change the primitive and remove this hack Kernel-Chronology * Change SqueakEpoch from ChronologyConstants - rename to UnixEpoch - change value to that of UnixEpoch * Replace all uses of SqueakEpoch with UnixEpoch * change DateAndTime class>>epoch to use UTC KernelTests-Chronology * Fix all tests to pass, except the DateAndTime*EpochTest classes, which are incredibly redundant and should be removed (Issue 5910: [Cleanup]: Gut DateAndTimeDosEpochTests) * Removed many magic numbers * cleaned and refactored Other * Fix MailMessage and MessageList to use new epoch
Cheers,
Sean |
Re: Epoch returns local offset
|
|
Sean,
I have very little time because I need to prepare stuff for the PharoConf, so I haven't read all the mails and code that you produced on this subject. But are you sure that this is incorrect ? I am mean, combining the clock seconds with the local offset should yield a proper time, no ? The TZ of the clock is then cancelled out as far as I see it. This is code taken from https://github.com/svenvc/ztimestamp ZTimestamp class side now "Create and return a new ZTimestamp equal to the current system time" ^ self fromClockSeconds: (self clockSeconds - self clockTimezoneOffset) fromClockSeconds: seconds "Create and return a new instance from a specific number of seconds since our clock epoch, see #now" ^ self new jdn: self clockEpoch julianDayNumber + (seconds // 86400) secs: self clockEpoch secondsSinceMidnight + (seconds \\ 86400) clockEpoch "Return the epoch of the clock that we use as an instance (cached), see #now" ^ ClockEpoch ifNil: [ ClockEpoch := self year: 1901 month: 1 day: 1 ] clockSeconds "Return the total seconds count of the clock that we use as an Integer, see #now" ^ Time totalSeconds clockTimezoneOffset "Return the timezone offset of the clock that we use as an Integer seconds (cached), see #now" ^ ClockTimezoneOffset ifNil: [ ClockTimezoneOffset := DateAndTime localTimeZone offset asSeconds ] I would love to learn/discuss more, later on. It feels like you are changing dangerous things, someone else should check this out. But cleanups are of course welcome. Sven On 17 May 2012, at 21:11, Sean P. DeNigris wrote: > Fix in inbox: Name: SLICE-Issue-5913-Remove-Squeak-epoch-SeanDeNigris.1 > > This was a complicated change that's obviously at the core of the system. > Although all 385 of KernelTests-Chronology tests pass[1], I'd really > appreciate some feedback and testing... > > [1] except the DateAndTime*EpochTest classes, which should be removed; see > below > > General > * Update all comments referencing the Squeak Epoch > * There is a VM primitive that returns current seconds since the Squeak > epoch. For now, I have adjusted all users of this primitive for the Unix > epoch, but it would be cleaner to change the primitive and remove this hack > > Kernel-Chronology > * Change SqueakEpoch from ChronologyConstants > - rename to UnixEpoch > - change value to that of UnixEpoch > * Replace all uses of SqueakEpoch with UnixEpoch > * change DateAndTime class>>epoch to use UTC > > KernelTests-Chronology > * Fix all tests to pass, except the DateAndTime*EpochTest classes, which are > incredibly redundant and should be removed (Issue 5910: [Cleanup]: Gut > DateAndTimeDosEpochTests) > * Removed many magic numbers > * cleaned and refactored > > Other > * Fix MailMessage and MessageList to use new epoch -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill |
Re: Epoch returns local offset
|
Administrator
|
Hey Sven! It started out as a question about the offset of the epoch. From the responses, and some of my own problems in the past, it seems clear that having an epoch without a specific timezone does not work (see my example earlier in the thread of converting to seconds, moving to a different timezone, and converting back to a DateAndTime). As David Lewis mentioned, we're back in the world of DOS (which is how I got into this mess to begin with - fixing ZipArchive led me to DOS times, led me to SqueakEpoch...). The only way out that I can see is to assume that all times-as-seconds are in a reference timezone, and the Unix epoch already exists, is widely known, and specifies UTC, so I used that, as David suggested. Sean
Cheers,
Sean |
Re: Epoch returns local offset
|
|
In reply to this post by Sean P. DeNigris
On 17 May 2012, at 21:11, Sean P. DeNigris wrote: > This was a complicated change that's obviously at the core of the system. > Although all 385 of KernelTests-Chronology tests pass[1], I'd really > appreciate some feedback and testing... I want to have a look, but after the conference. |
|
|
In reply to this post by David T. Lewis
The choise of epoch is arbitrary, Calendrical Calculations,
set it to Rata Die 0 and defines all the ones for the other calendars
- Mayan, Gregorian, Julian, Persian ... - accordingly. I did implement the Python equivalent of the Common Lisp code from the book, you can browse both in my pycalcal project page
(Python code is in the zip distribution). I have a yet unfinished implementation in Smalltalk on squeaksource called Calendrica.
Bye Enrico On Thu, May 17, 2012 at 2:26 AM, David T. Lewis <[hidden email]> wrote: (cross posting to squeak-dev) Enrico Spinielli "Do Androids dream of electric sheep?"— Philip K. Dick "Hear and forget; see and remember;do and understand."—Mitchel Resnick "He who refuses to do arithmetic is doomed to talk nonsense."—John McCarthy |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |