PostgreSQL 9.1 timezones - postgresql

I'm using postgresql to store some dates on a database.
In my application it is fundamental that it is completely aware of timezones and I was conducting some basic tests, between, client, server and database.
I'm sending the dates from a browser's application I did in GWT and read the dates on postgresql.
My tests:
The client is always in GMT Timezone, and I'm sending always the same date for each case.
13/04/2012 00:00:00 GMT+00
On posgres I'm changing timezones for each test. Between tests I'm removing all dates from the table.
To change the timezone on the posgres, I do it on the {PostgreSQL HOME}\9.1\data\postgresql.conf setting the timezene to the one I want.
Tests:
Client: 13/04/2012 00:00:00 GMT+00
1st test - posgres EST - 12/04/2012 19:00:00-05
According to postgresql documentation EST = GMT - 5
2nd test - posgres GMT + 5 - 12/04/2012 19:00:00-05
3rd test - posgres GMT - 5 - 13/04/2012 05:00:00+05
Now my question rises: According the the docs, EST = GMT - 5. So why am I reading it the other way around?
Am I missing something here?
EDIT
Technical aspects of my tests:
On the client I send this: 2012 Apr 13 00:00:00 GMT+00.
On the server I'm using JDBC to write on the db: convert java.utils.date to
java.sql.timestamp
java.sql.Timestamp sqlTimeStamp = new java.sql.Timestamp(date.getTime());
(date is java.utils.Date that comes from the client)
set the prepared statement
PreparedStatement ps = con.prepareStatement("INSERT INTO teste.dates (dates_tz, dates_ntz) VALUES (?, ?);"
ps.setTimestamp(1, sqlTimeStamp); ...
For the record, this is just something I want to understand, because overall it works well for my purposes..

Consider that warning in the documentation:
Another issue to keep in mind is that in POSIX time zone names,
positive offsets are used for locations west of Greenwich. Everywhere
else, PostgreSQL follows the ISO-8601 convention that positive
timezone offsets are east of Greenwich.
It looks like the opposite signs towards GMT you're seeing is exactly the effect of that divergence.
The timezone specified in postgresql.conf is probably interpreted with POSIX rules, but it's later displayed by SQL with ISO-8601 rules (the one that anyone really uses).

When the clock on the wall shows 2012-04-13 00:00 in a time zone '+5', the time in London (GMT or UTC) is 2012-04-12 19:00.
If you live in the USA, your local time zone may be '-5'. When it's midnight there, it is 05:00 in the morning in London.
That's just how it is. This detailed answer about handling of time zones in PostgreSQL may help you understand.

Related

PostgreSQL: Can't get timezones with DST to work properly

I'm trying to figure out how Postgres handles DST in combination with intervals. Specifically I want to allow my users to create events with recurring dates - e.g. everyday at 16:00 local time.
For what I'm doing I need to store the first date in the user's local time, and then add a number of days to it, without changing the time of day in the user's local time. I was hoping that timestamptz with a full timezone name (so it knows when to apply DST?) combined with simple 1 day intervals would do the job - but it fails at my simple example:
Germany uses CET (+1:00) and switches to CEST (+2:00) at 2:00 in the morning on March 28.
Tunesia uses CET all year.
Thus I expected, that using a timestamptz on March 27 and adding 1 day to it, I'd see a different utc-offset in Berlin, and no change in Tunis - but they both changed the offset equally, as if Tunis was using DST:
select
'2021-03-27 16:00:00 Africa/Tunis'::timestamptz as "tunis_before_dst",
'2021-03-27 16:00:00 Africa/Tunis'::timestamptz + INTERVAL '1 day' as "tunis_after_dst",
'2021-03-27 16:00:00 Europe/Berlin'::timestamptz as "berlin_before_dst",
'2021-03-27 16:00:00 Europe/Berlin'::timestamptz + INTERVAL '1 day' as "berlin_after_dst"
results in:
tunis_before_dst: '2021-03-27 16:00:00+01'
tunis_after_dst: '2021-03-28 16:00:00+02'
berlin_before_dst: '2021-03-27 16:00:00+01'
berlin_after_dst: '2021-03-28 16:00:00+02'
Looking through pg_timezone_names, I can see that my Postgres instance is aware of Africa/Tunis not having DST - so I'm wondering why it's changing the UTC offset for it then.
I guess it's obvious that timezones and DST are very confusing to me, but am I doing something wrong handling them or is timezonetz not what I think it is?
Rant first. The concept of DST is breathtaking nonsense. Even the name is obvious BS. "Daylight Saving Time". No daylight has been saved. I can't believe the EU still did not manage to get rid of it, even though the overwhelming majority wants it gone, and it's been consensus to scrap it for a while now.
With that out of my system, the primary misunderstanding is this: you assume that the data type timestamp with time zone would store time zone information. It does not. Becomes obvious here:
Thus I expected, [...] I'd see a different utc-offset in Berlin, and no change in
Tunis - but they both changed the offset equally
The time zone offset you see in the output is the offset determined by the current timezone setting of your session. Time zone serves as input / output modifier / decorator. Postgres always stores UTC time internally. And no time zone information whatsoever.
The type name is a bit deceiving there. It has been known to fool the best:
Time zone storage in data type "timestamp with time zone"
Once you've grasped that concept, the rest should become obvious.
To preserve the local time (wall clock time of day), use the data type timestamp without time zone (timestamp), or even just time (never use the broken timetz), and store time zone information additionally - ideally the time zone name ('Europe/Berlin' like you have it), not a time zone abbreviation or a numeric offset.
timestamp with time zone (timestamptz) is the right choice to store unique points in time, independent of any time zones. The time zone offset is just an input modifier. Both of the following literals result in the same timestamptz value exactly, because both time zones happen to apply the same offset at this time of the year:
'2021-03-27 16:00:00 Africa/Tunis'::timestamptz
'2021-03-27 16:00:00 Europe/Berlin'::timestamptz
But these differ by one hour, because the German offset has changed according to the local DST regime:
'2021-03-28 16:00:00 Africa/Tunis'::timestamptz
'2021-03-28 16:00:00 Europe/Berlin'::timestamptz
Related:
Ignoring time zones altogether in Rails and PostgreSQL
Preserve timezone in PostgreSQL timestamptz type

Dates and timezones in Hive

I am struggling to understand how Hive deals with dates and timezones:
select item_id, cal_dt from ds where item_id = 7208582515 and cal_dt='2019-02-11';
7208582515 2019-02-10
I know it has to be a timezone issue. It's 11 pm PDT right now (same as the Hadoop cluster time, I think) but Hive (1.2) is running on a node without any timezone (UTC).
Previously, I had a bigger issue where a query with this condition:
next_dt = date_add(cal_dt,1)
It didn't work on the clock change dates. I think that was because my TZ was set to America/Los_Angeles so I unset it.
I don't know what's going on. I didn't expect dates to be affected by the timezone. What's the right thing to do?

Mongodb date is off by 1 hour

I am running mongodb on ubuntu server. The server time is
root# date
Thu Sep 13 21:15:58 BST 2012
But when I run the following command I get a different result
root# mongo
MongoDB shell version: 2.2.0
connecting to: test
> new Date()
ISODate("2012-09-13T20:15:58.670Z")
There is exactly one hour difference. When I update a documents updated_on field with php using MongoDate(), the value of the field is still 1 hour off.
[EDIT]
Actually I just checked my php error log and the time in the log file is 1 hour off as well
[13-Sep-2012 20:11:14 UTC] Log Message (Time should be 21:11:14)
Mongo tells you
2012-09-13T20:15:58.670Z
Z = Zulu time / Zero offset / UTC. You can also express the time in that TZ as 2012-09-13T20:15:58.670+00:00, as defined in the ISO8601 standard by the way.
BST is UTC+1. So, they are the same time but in different time zones.
You can resolve this issue by displaying the DateTime with ToLocalTime method.
MVC C# Example: #Model.StartDate.ToLocalTime()
This is due to the way MongoDB store datetime in BST format. So the daylight savings time or the time zone of the server will have an effect on the actual date time returned to the application. This simple code will be able to format as usual with ToString("dd MMMM yyyy hh:mm tt") or any other format based on your requirements.
Here you need to understand a concept in time setting in clocks called daylight saving time. In some countries around the world the clock is advanced by 1 or more hours to experience day light by one more hour. The difference between IST and GST is 5.30 hrs but the actual time difference is between New Delhi and London time is 6.30 hrs. See this article from 4GuysFromRolla for setting and using server time.
On windows change your timezone.
Controll Panel -> Date and Time -> Change on timezone -> (UTC) Coordinated universal time.
And then just change your time

converting db2 datestamp to Unix timestamp

How can i convert 2012-04-12 00:00:00 to a unix timestamp in DB2. is there any inbuild function available in sql s
Thank you.
Using the DAYS and MIDNIGHT_SECONDS is much more precise than TIMESTAMPDIFF:
SELECT
86400*(DAYS(CURRENT TIMESTAMP - CURRENT TIMEZONE)-DAYS('1970-01-01'))
+ MIDNIGHT_SECONDS(CURRENT TIMESTAMP - CURRENT TIMEZONE)
"UNIX_TIMESTAMP"
FROM SYSIBM.SYSDUMMY1
By Unix timestamp I assume you mean the number of seconds (or whatever) since 1970-01-01 00:00:00 UTC.
There is no built in functionality for this in DB2 (as of V6R1).
You're also up against the following issues:
All timestamps in DB2 are 'local time' - they contain no timezone information, and all CURRENT_TIMESTAMP writes are based on what time the requesting system thinks it is, not the host.
Daylight savings time changes frequently. You would need to add overhead to manage this for your conversion.
The TIMESTAMPDIFF function returns an estimate, not an exact value. You could probably survive for the years/months durations, over sufficient differences, but days aren't likely to cut it.
Timestamp arithmetic is imprecise (among other things, months are assumed to be always 30 days in length...)
Your best bet will be to start using DAYS (which returns the number of days since 0001-01-01). Keep in mind you better do everything in UTC, because it will not take DST into account.

facebook api date format

I've been working on facebook application. But I've faced with strange bug(?).
It I'm trying to get detailed info about any event using graph api start_date differs from the one if I'm trying to get it using fql. for example:
https://graph.facebook.com/209798352393506/ - start date is 2011-05-26T19:00:00
https://api.facebook.com/method/fql.query?query=select%20eid%2C%20name%2C%20tagline%2C%20pic%2C%20host%20%2C%20start_time%20from%20event%20where%20eid%20%3D209798352393506 - start time is 1306461600. Which in human readable format equals to Fri, 27 May 2011 02:00:00 GMT.
As you can see difference between got dates is 5 hours. Somtimes I'm getting dates which differ for 8 hours, sometimes - 6.
Correct date is the first one:
http://www.facebook.com/events/209798352393506/
I can't figure out what happens. All events I'm trying to view are from Denmark. My timezone is Europe/Kiev. Difference is 1 hour.
Is this a facebook's bug? Or documented feature? Or am I doing something wrong?
Link to the documentation or another answer in stackoverflow would be enough.
Here is two events
http://www.facebook.com/events/290600150977115/ - starts on 2012-03-22 at 20:00
http://www.facebook.com/events/289501924395338/ - starts on 2012-03-03 at 21:00
But. Using FQL I'm getting that first event starts on 2012-03-23 at 04:00. Difference is 8 hours. And the second one starts on 2012-03-04 at 06:00. In this case difference is 9 hours. Why???
It was because of daylight saving time.
Time difference between me and facebook(Los Angeles) sometimes was 8 sometimes 9 hours, because there was a moment when Denmakr alredy changed their time to summer time and los angeles - not.
The problem occured when event started "in winter time" and finished in summer time. In this case I needed to add one hour.
Facebook is weird.
From /fql/insights/
The end of the period during which the metrics were collected, expressed as a unix time (which should always be midnight, Pacific Daylight Time) or using the function end_time_date() which takes a date string in 'YYYY-MM-DD' format.
2011-05-26T19:00:00 ===> 2011-05-26T19:00:00 PDT ===> Fri, 27 May 2011 02:00:00 GMT.