Time zone handling

Subscribing (not confirming)

subscribing

subscribing

Same issue here.

EDIT: Based on the previous thread regarding Drupal 6 (referenced above), I set the date field's time zone handling to 'UTC.' In order to do that, I had to first delete all nodes with that date field. (If you can't delete these nodes, you can create a new date field for this content type.)

After this, I imported my nodes, and they all appeared with correct date/time.

Yes, if I can delete ALL nodes, than i can change the timezone.

But the feeds-import imports every line of the CSV-file twice, please look at the screenshot (only one line of the CV-file is in this month).

I think, this is no correct import.
Something is wrong.

Please help me.
Thanks in advance

wusel,

First off, I think this is a separate issue that should be moved to a new thread.

But as to your question... that is bizarre. I can't replicate the problem. I have two thoughts:

1.) Does the screenshot result after importing the CSV file only once? Try deleting all the imports (www.example.com/import/node/delete-items), checking the calendar to be sure it's clear, and then re-importing the file.

2.) In your 'content' list, is each entry appearing twice or only once? If it's appearing only once, check your calendar view -- how are the fields set up?

@kscott22

yes, in my content-list is only one event per CSV-line.
But the calendar-view shows TWO entries with the same date and time, but the start-time (where the top of the box, which shows the content-fields, begins) of the "TWO entries" in the view are different.

How are your fields set up in your view?

@kscott22

I attach the view-export.
I hope, this helps you.

Thanks

I can say that I am looking at this in relation to the ical parser for 7. There a set of factors at play here; not least that there are 5 different timezone settings on a field. The storage is for most of them in the database as UTC, the date is converted on submission, and then again on display as appropriate.

With the ical parser we usually have the timezone attached to the date. I say usually. However, on some feeds it is missing. And there is also defined in the standard a type of 'floating' date, that should be the same date no matter the timezone. But with missing timezones there is also the question of suitable defaults.

How is this working with the csv parser? What is the expected behaviour, where do the inputs come from? I've never used it, so..

Anyway at the moment I have a very hackish patch on the parser; which presently I am not proposing as a fix; but I will attach for anyone want to see what I mean, or just try it out. I will review it again as I continue with the ical parser; and grok exactly what date is doing as items are submitted.

I have this issue as well. I'm trying to import event information from a xml-file and managed to combine two separate date fields into the correct datetime format. But for some reason all the imported events have two hours more (size timezone is set to GMT +0200) when I view them, compared to events added manually by users.

The field doesn't have any timezone conversion enabled, but for some reason when I import a date field with feeds where the time is 2011-12-10T20:30:00, it will be stored 2011-12-10T22:30:00 in the database. If I create a event as a user and type in the same date (by using popup mini-calendar), it doesn't get two hours more in the database. This means that the date is not converted for display, but something happens differently between user saving the field and Feeds saving it. What happens beats me, since both should get the same input and are stored in the database as they are displayed.

(it seems like the user input would be compared/transformed first to GMT and then back to site timezone, because the field doesn't have timezone conversion, but Feeds skips this last part or something. I have also tried to set the field's timezone to the same as the site's timezone, but without luck.)

And I tried the solution mentioned in #4, which actually seems to work. I was sure that then if the user adds an event manually, it would show different time, but it doesn't seem to be the case.

(note this is a question on #13) Do you know when it comes from the XML does the time have timezone information attached to it? Or is feeds none the wiser and just assuming it's UTC? Hence that it works with UTC as the timezone for the field?

You can see from my example in #12 the format and it does _not_ have timezone information, because it's not supposed to have it. If I would choose timezone handling for the field, then there would be +0200 at the end.

Actually there isn't any +0200 at the end, the date is automatically saved in different timezone. So I don't know how this field knows to which timezone it belongs...

When you add a "date"-field to a content type, you can set the timezone of that field.
If this content-type is used, you cannot change the timezone.

I normally I set it to UTC to avoid timezone-calculations, so the timezone of those "date"-fields is different to my site-timezone (+0200).

May be, this info can help you.

I noticed it works like this, but I don't think it should work like this. There's also an option "No timezone conversion", but if I choose that, then the dates are actually converted to UTC, which means that they will get +3h in my case.

The correct behavior in my opinion would be so, that if the field's timezone is set to UTC, it should display for example 20:00 instead of 17:00 in my case, even if the user inputs 17:00. If the field doesn't have any timezone, it should ALWAYS display exactly the same time which was inputted, no matter which is the site's or user's timezone at the moment or during the saving of the content. Do you agree?

#18:
My strategic plan:

Feeds imports the date-fields with optional timezone, e.g. format "YYYY-MM-DDTHH:MM:SS+HHMM" (every imported event may be in another location with another timezone - let drupal calculate the time-correction) #1243760: Import ignores Timestamp in the imported data!
It should also be possible, to import a new field with the language of the new node #1247536: Allow users to choose node import language.

A new Feeds configuration at "http://example.com/admin/structure/feeds/edit/[machine_name]/mapping": a new choice of the timezone for every date-field, nice to have: user can instruct drupal to ignore the timezone in the import-field, then the user can set the timezone-default here. But at the moment, I don't know what and how this should be implemented to show all needed individual situations)!

If none of the previous cases applies:
Feeds imports the date-data (no timezone given in the data source) without any timezone-change as UTC (because the user, who imports, should know the correct time and can put it in the data source)!

The timezone of the date-field in the node shall only be used, when the date is viewed, but never while an import! Viewing and importing shall be two different things!

Please note: until now drupal stores date-fields in UTC!!!

#19 for examples the tests in http://drupalcode.org/project/parser_ical.git/blob/refs/heads/7.x-2.x:/t... might help. I've tried to comment them as well as I can. It should give a reasonably broad sample how the date timetimezones are coming in, and also the different destination field settings - and if they work as expected at the moment.

#20:
That may be very nice, but I'm not a PHP programmer:

I cannot find something like that in my installed modules Feeds and Date.
So I cannot test this code and at the moment I don't understand this code.

I am patiently and wait.

OK.

To clarify for anyone else the link above is one of the tests in the ical parser. It lists the different types of date with and without timezone that are commonly inputted via feeds, and the settings of the date field they get mapped to. It also lists what the desired values would be (or if I'm not sure there is a comment).

I haven't tested ekes's patch in comment #11 but I did post a potential fix in a patch on a similar issue:
#722740: Feeds Date mapper converts imported dates to GMT unless in UNIX timestamp format

(These issues appear to be duplicates, someone else can make that call) Please try my patch on the other issue and post your review

Let's consolidate all of these timezone issues.

#722740: Feeds Date mapper converts imported dates to GMT unless in UNIX timestamp format.