Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option --utc to use UTC dates in snapshot names instead of the local time zone. #27

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

fungus
Copy link

@fungus fungus commented Apr 29, 2014

For /issues/19

Enabling this as a command line switch is the best option, IMHO. Default should obey time zone set on machine.

@dajhorn
Copy link
Member

dajhorn commented Apr 30, 2014

@fungus, this was the default for the 1.0.x series, but UTC is now the default because several systems broke during a daylight savings time change. The same kind of breakage could happen for a tzdata update.

We can add this kind of switch, but the default should be reversed.

Handle snapshot name collisions by destroying the previous snapshot.
@fungus
Copy link
Author

fungus commented Apr 30, 2014

That issue (zfsonlinux/pkg-zfs/issues/100) is really not about time zones, but instead is about snapshot name collisions. These can happen in other situations that using UTC does not fix.

IMHO, UTC should not be the default time representation. Obeying the local time zone should be the default. Nearly every other system tool obeys local time zone by default. It's the reason we set the system wide time zone, instead of leaving the system time zone at UTC.

UTC should be an option, for people who need it, like /pull/18, but not the default.

To solve the problem of snapshot name collisions, it would be better to either skip making this snapshot, or destroying the existing snapshot. I added a commit that will remove the previous snapshot.

What do you think?

@dajhorn
Copy link
Member

dajhorn commented May 1, 2014

I agree that defaulting to UTC is unconventional and arguably the wrong default, but it also solved a production issue and this is the first objection. Additionally, the default change went out in a release and I am reluctant to change behavior in-series.

Let's leave this ticket open for a while so that anybody with an interest can put a #meetoo on it.

@ezx
Copy link

ezx commented Jul 16, 2014

The problem with UTC dates that it is very confusing to figure out which date/time you need for a restore/clone. Perhaps a Unix timestamp in the snapshot name is better. It can be automatically converted to the local date when listing the snapshots and it is much more precise (to a second), which will reduce or even prevent name collisions. Or, another option is to write a script to convert currently used name format to the local date format when listing the snapshots.

@virtualguy
Copy link
Contributor

As a user i'd prefer the snapshot names followed the system time config to minimise confusion (an acceptable work around is to show +UTC in the snapshot name).

In the case of a collision, the snapshot should be given a unique suffux i.e. _1 I would hate for a snapshot to be automatically deleted, the current behaviour of emitting an error and doing nothing is definitely preferable to deletion/replacement

@dajhorn
Copy link
Member

dajhorn commented Oct 14, 2014

As a user i'd prefer the snapshot names followed the system time config to minimise confusion (an acceptable work around is to show +UTC in the snapshot name).

This could be implemented as a switch, but the current date format is in a sweet spot that works with things like the Samba .zfs/snapshot handler. (That feature alone makes it unlikely the default will change again in the near future.)

In the case of a collision, the snapshot should be given a unique suffux i.e. _1 I would hate for a snapshot to be automatically deleted, the current behaviour of emitting an error and doing nothing is definitely preferable to deletion/replacement

I intend to merge the --utc switch, but I still need to ponder whether something like the second commit fits.

My first impression is that breaks convention without a motivating reason and could mask misbehavior. Rather, anything creating snapshots more frequently than once per minute, which is the date format granularity, is likely to choke the host.

@luxflow
Copy link

luxflow commented Nov 17, 2016

UTC time is very hard to read since my timezone is far from UTC.
I hope that localtime is default or at least --local option to use localtime
I think that changing convention should be made before changing is too late

@megajocke
Copy link

megajocke commented Jul 8, 2017

IMO, the name should contain the UTC time, though having local time as an option might make sense.
A UTC timestamp is machine-readable, with a unique representation for a certain point in time.
AFAIK, MS-DOS used to store file timestamps in local time with headaches as result.
Modern filesystems tend to use UTC.

Local time depends on time zones and DST, and their definitions change every now and then.
Also for DST there is an overlap which means there are two different points in time (UTC) with the same local time representation.

For a local time option, date --iso-8601=minutes representation might make sense because it contains the offset to UTC at that point in time. At DST changes, the trailing offset part will change making the representation unique.

@jbnance
Copy link
Contributor

jbnance commented Dec 22, 2017

I have created #77 which leaves the default as UTC but adds a program option --local-tz to allow using the local system's timezone.

@enoch85
Copy link

enoch85 commented Nov 24, 2018

#meetoo on it.

Me too. :)

@alfarahat
Copy link

dears, did you solved the conflict ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants