Smalltalk › Pharo › Pharo Smalltalk Users

Working with timezones

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Esteban A. Maringolo

Working with timezones

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 :)

NorbertHartl

Re: Working with timezones

Am 10.07.2014 um 23:26 schrieb Esteban A. Maringolo <[hidden email]>:

> 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

Sven Van Caekenberghe-2

Re: Working with timezones

In reply to this post by Esteban A. Maringolo

On 10 Jul 2014, at 23:26, Esteban A. Maringolo <[hidden email]> wrote:

;-)

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

Esteban A. Maringolo

Re: Working with timezones

2014-07-10 19:42 GMT-03:00 Sven Van Caekenberghe <[hidden email]>:

>> 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

Esteban A. Maringolo

Re: Working with timezones

In reply to this post by Sven Van Caekenberghe-2

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" <[hidden email]> escribió:

On 10 Jul 2014, at 23:26, Esteban A. Maringolo <[hidden email]> 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

Stephan Eggermont-3

Re: Working with timezones

In reply to this post by Esteban A. Maringolo

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

Sven Van Caekenberghe-2

Re: Working with timezones

Exactly !

On 11 Jul 2014, at 11:26, Stephan Eggermont <[hidden email]> 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

Paul DeBruicker

Re: Working with timezones

In reply to this post by Stephan Eggermont-3

Additionally I think its helpful to remember that timezones are political constructs and so are completely arbitrary and open to change based on the whims of political leaders e.g.

https://en.wikipedia.org/wiki/Time_in_Russia#Daylight_saving_time

So best keep them out of your code, near the presentation layer, as much as possible as Stephan recommends.

Stephan Eggermont 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

Esteban A. Maringolo

Re: Working with timezones

2014-07-11 13:30 GMT-03:00 Paul DeBruicker <[hidden email]>:
> Additionally I think its helpful to remember that timezones are political
> constructs and so are completely arbitrary and open to change based on the
> whims of political leaders e.g.
>
> https://en.wikipedia.org/wiki/Time_in_Russia#Daylight_saving_time
>
> So best keep them out of your code, near the presentation layer, as much as
> possible as Stephan recommends.

Yeap, and using UTC whenever possible to have a "zero" point of
reference. Even when using a predefined time offset would be possible.

After reading W3's TR I mentioned before, I learnt there is a reason
to store timezone information if you have to deal with dates and times
in the future when using incremental time representations (like the
ones used by most systems). In such case a change in DST.

Regards,

Esteban A. Maringolo