- Pharo-users - lists.pharo.org

FFI on Linux

by Annick Fron

What should be the name of the module in FFI on Linux ? For instance, if there is a shared lib under /usr/lib named gstreamer-1.0 should it be the name of the shared lib or of a module like libgstreamer-1.0.so ? Do I need to put the full path to the lib or is /usr/lib understood by the call ? Annick

July 11, 2014

Re: [Pharo-users] Working with timezones

by Sven Van Caekenberghe

Exactly ! On 11 Jul 2014, at 11:26, Stephan Eggermont <stephan(a)stack.nl> wrote: > Esteban wrote: >> Anyhow this is too much to add to my app without giving it proper thinking. So let's KISS. > > If you only work with a single server/all servers in the same timezone that translates to: > - Do everything in local time or UTC, have one place where you know your zone, > - Store all time/date without timezone. > - Have in your session timezone information you get from the browser. > - Store in the user info their preferred/last used timezone > - Translate on the outside > > Stephan

July 11, 2014

Re: [Pharo-users] Should I be reporting bugs in Pharo 3.0?

by Tim Mackinnon

Nicolai - I have just seen that you have a fix for one of the Nautilus issues I raised (awesome). Forgive me - but I don't yet know how to load up a slice and test it (but am willing to learn, so I can perhaps help more in the future). I've loaded up the latest Pharo 4.0 image - luanched monticello - but how do I load a slice? If its written up somewhere - I'm happy to go and read. I'm assuming the idea is that when you report a bug, if someone fixes it - you try and verify it and then I can mark it resolved in Fogbugz? Tim -- View this message in context: http://forum.world.st/Should-I-be-reporting-bugs-in-Pharo-3-0-tp4767284p476… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 11, 2014

Re: [Pharo-users] Working with timezones

by Stephan Eggermont

Esteban wrote: >Anyhow this is too much to add to my app without giving it proper thinking. So let's KISS. If you only work with a single server/all servers in the same timezone that translates to: - Do everything in local time or UTC, have one place where you know your zone, - Store all time/date without timezone. - Have in your session timezone information you get from the browser. - Store in the user info their preferred/last used timezone - Translate on the outside Stephan

July 11, 2014

Re: [Pharo-users] Working with timezones

by Esteban A. Maringolo

So I searched around and ended at http://www.w3.org/TR/timezone Now I can picture the kind of issues you might have to deal with when using timezones. It gets scary. Also I learnt that timezone and time offset are not synonyms. Anyhow this is too much to add to my app without giving it proper thinking. So let's KISS. Regards, El jul 10, 2014 7:43 PM, "Sven Van Caekenberghe" <sven(a)stfx.eu> escribiÃ³: > > On 10 Jul 2014, at 23:26, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > > What is the best way to work across timezones? > > > > Today my app assumes a global, shared, timezone for data input, storage, > etc. > > I want to make this configurable, and for that purpose I > > > > For what I read and thought about, I understand that the best way to > > avoid any complication is to store and transfer (between > > client/server) everything in UTC, and use timezone offset only to > > convert to/from in order to display the Date and Time. > > > > Does anybody have a good article regarding working across timezones? > > Any tip or suggestion for its use with PostgreSQL and GLORP? > > > > Thanks in advance. > > > > Esteban A. Maringolo > > > > ps: And I guess I now understand the purpose of ZTimestamp :) > > ;-) > > Not only that, there is also ZTimezone with support for the Olsen timezone > database. > > Note that going from local time to UTC and vice versa depends not just on > the TZ but also on the timestamp itself (DST transitions), with possible > gaps and doubles (turn the clock forward/backward), making durations across > the DST transition weird ;-) > > Furthermore, a date (or start/end of a day) is also TZ dependent (Saturday > starts earlier/later for me than for you). For example, 'notify me if > something happens on Monday' is trickier than it would seem. > > Even though Norbert is right that you can use/mix any/all timezones, the > only way to remain sane, IMHO, is to store everything in UTC and only > convert to local TZ when presenting (this can be really on the client like > you suggest or in Seaside or reporting code on the server). You will also > need more the just a global setting, you need this per session ! > > Anyway, this is how we do it. > > Sven > > >

July 11, 2014

Re: [Pharo-users] Working with timezones

by Esteban A. Maringolo

2014-07-10 19:42 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> ps: And I guess I now understand the purpose of ZTimestamp :) > > ;-) > > Not only that, there is also ZTimezone with support for the Olsen timezone database. > > Note that going from local time to UTC and vice versa depends not just on the TZ but also on the timestamp itself (DST transitions), with possible gaps and doubles (turn the clock forward/backward), making durations across the DST transition weird ;-) Can you expand this? DST can be a complication too, but how to deal with that with current tools/libraries? > Furthermore, a date (or start/end of a day) is also TZ dependent (Saturday starts earlier/later for me than for you). For example, 'notify me if something happens on Monday' is trickier than it would seem. I agree. Such calculations should always use a TZ for the client, even when the client is an agent/service, maybe impersonating the real user. > Even though Norbert is right that you can use/mix any/all timezones, the only way to remain sane, IMHO, is to store everything in UTC and only convert to local TZ when presenting (this can be really on the client like you suggest or in Seaside or reporting code on the server). Seems to be the "most recommended way" of dealing with TZ interactions. > You will also need more the just a global setting, you need this per session ! Sure. Well... I guess I'll have to add ZTimestamp to the supported column types of GLORP tables. If you already have something for Postgres (other than casting TimeStamp or DateAndTime), I'll really appreciate it. Regards! Esteban A. Maringolo

July 10, 2014

Re: [Pharo-users] Working with timezones

by Sven Van Caekenberghe

On 10 Jul 2014, at 23:26, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > What is the best way to work across timezones? > > Today my app assumes a global, shared, timezone for data input, storage, etc. > I want to make this configurable, and for that purpose I > > For what I read and thought about, I understand that the best way to > avoid any complication is to store and transfer (between > client/server) everything in UTC, and use timezone offset only to > convert to/from in order to display the Date and Time. > > Does anybody have a good article regarding working across timezones? > Any tip or suggestion for its use with PostgreSQL and GLORP? > > Thanks in advance. > > Esteban A. Maringolo > > ps: And I guess I now understand the purpose of ZTimestamp :) ;-) Not only that, there is also ZTimezone with support for the Olsen timezone database. Note that going from local time to UTC and vice versa depends not just on the TZ but also on the timestamp itself (DST transitions), with possible gaps and doubles (turn the clock forward/backward), making durations across the DST transition weird ;-) Furthermore, a date (or start/end of a day) is also TZ dependent (Saturday starts earlier/later for me than for you). For example, 'notify me if something happens on Monday' is trickier than it would seem. Even though Norbert is right that you can use/mix any/all timezones, the only way to remain sane, IMHO, is to store everything in UTC and only convert to local TZ when presenting (this can be really on the client like you suggest or in Seaside or reporting code on the server). You will also need more the just a global setting, you need this per session ! Anyway, this is how we do it. Sven

July 10, 2014

Re: [Pharo-users] Working with timezones

by Norbert Hartl

Am 10.07.2014 um 23:26 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com>: > What is the best way to work across timezones? > > Today my app assumes a global, shared, timezone for data input, storage, etc. > I want to make this configurable, and for that purpose I > > For what I read and thought about, I understand that the best way to > avoid any complication is to store and transfer (between > client/server) everything in UTC, and use timezone offset only to > convert to/from in order to display the Date and Time. > > Does anybody have a good article regarding working across timezones? > Any tip or suggestion for its use with PostgreSQL and GLORP? I think the only purpose is to have a reference point that is common. It doesn't matter if you transfer dates and times in UTC. That is what the offset is for. You can get the local time from a client but you store it in UTC (which will do the calculation of the offset). If you have a interface to a client you just deliver a correct offset but UTC is good thing here. The proper display of timezones is the duty of the client. If you produce web pages you need to get the timezone information from the user or in a web environment you do that locally with javascript. Hope that helps anyhow, Norbert

July 10, 2014

Working with timezones

by Esteban A. Maringolo

What is the best way to work across timezones? Today my app assumes a global, shared, timezone for data input, storage, etc. I want to make this configurable, and for that purpose I For what I read and thought about, I understand that the best way to avoid any complication is to store and transfer (between client/server) everything in UTC, and use timezone offset only to convert to/from in order to display the Date and Time. Does anybody have a good article regarding working across timezones? Any tip or suggestion for its use with PostgreSQL and GLORP? Thanks in advance. Esteban A. Maringolo ps: And I guess I now understand the purpose of ZTimestamp :)

July 10, 2014

Re: [Pharo-users] FFI Basic

by ClÃ©ment Bera

Well the method with the code you give was compiled without any problem in my image (Pharo #30851 with FFI loaded with configuration browser as explained in the other thread). Perhaps this is related to your bug in the other thread where you were (probably) missing a package ? 2014-07-10 18:15 GMT+02:00 Annick Fron <info(a)afceurope.com>: > > Hi, > > I made another attempt , a very basic one on window : trying to use the > abs method in the standard lib. > > abs: aNumber > > <apicall: int 'abs' (int) module: 'c:\windows\system32\msvcr100.dll'> > self externalCallFailed > > I get the error âcannot return the given typeâ. > > But now if I use long as argument and long as return it works. > > Annick >

July 10, 2014